Some questions about cache of graph, especially tx graph

[Bob]

List questions first:

1. Does graph instance cache any orient element it encountered, no matter the tx commit or the graph got returned to pool?

2. Does a tx commit updates the cache of another graph/thread? If no, it means the cache doesn't behavior like a unified cache such as hibernate 2nd-level cache.

Sorry I forgot to mention orientdb version. I tried 2.1.5, and then 2.1.7, and then 2.1.8. However I don't think it quite relates to minor version.

I ask the questions since I encounter troubles recently with orientdb.

I try to use Vert.x 3 and OrientDB (Embeded Server) in an application. Vert.x is aync, thus the thread local mode is not usable anymore. The solution is to use OrientGraphFactory to setup a pool(using plocal). For each database task, retrieve a graph instance and then call makeActive. The code is like this (language is kotlin):

fun graph(factory: OrientGraphFactory = Injekt.get()): OrientGraph {
    val g = factory.tx
    g.makeActive()
    return g
}

If the task does modification, graph.commit will get invoked, and finally, graph.shutdown will be called. 

And all databse tasks run in work threads, however, there's no static bound between graph instances and threads.

The trouble I encountered is the same query conditions get different results. For example,

  an order, with status "Payed" at some point;

  and some time later, another operation changes the status to "End";

  on a web page, it shows the result as "End" sometimes and "Payed" for the rest.

After this question happened, I try to replace tx with noTx when no tx needed, however the question continued. Now I try to invalidate localcache.

fun graph(factory: OrientGraphFactory = Injekt.get(), txRequired: Boolean = true): OrientBaseGraph {
    val g = if (txRequired) factory.tx else factory.noTx
    g.makeActive()
    g.rawGraph.localCache.invalidate()
    return g
}

I'll update the result  tomorrow.

And according to my reading of the code of orientdb, the transaction will begin immediately after graph retrieved and committed, not when a modification occurred that the manual described.

[Bob]

I almost confirmed, that the cache behaves quite strange. Though maybe I need more time to observe the status.

So the question changed.

If the graph is the interface of database, then it should admit the promise -- READ_COMMITED. Any query should return the committed data, no matter it is in a different thread, or different connection, unless the transaction has already loaded an outdated version. Or at least the apis load from this kind of cache first should be a special set.

[Andrey Lomakin]

Hi Bob,

I agree with you, but do you have any isolated test to confirm your doubts about issue in transaction isolation, or any way for us to reproduce given issue ?

--

---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,
Andrey Lomakin, R&D lead. 

OrientDB Ltd

twitter:@Andrey_Lomakin linkedin:https://ua.linkedin.com/in/andreylomakin

[Bob]

Not now. I will create one and post reply once I done.

[Andrey Lomakin]

Sure,

Let us know by creating of issue, we will inspect provided code and if issue exists, we will fix it.