Transactions in an asynchronous environment

[joewhite86]

Hi,

I'm working on a driver/wrapper for neo4j and node.js: https://github.com/joewhite86/node-neo4j-embedded

Neo4j runs in a seperate JVM(Thread).

So to implement transactions I'm calling graphDb.beginTx() inside that thread.

Caused by the nature of javascript, multiple clients can call methods, that need transactions, asynchronously.

So there might be calls to beginTx more than once, before tx.finish() is called for the first transaction.

My guess is, that all calls to beginTx() will end up in nested transactions, when tx.finish() isn't called yet, right?

Regards,

Jochen Weis

[Chris Vest]

Hi,

How does the embedding work? Do you load the JVM into Node.js as a C/C++ library?

The Neo4j Core API is thread-safe provided you manage your thread-bound transactions properly, which is obviously going to be a dragon in the room if you have one thread multiplexing many different transactions. Preferably people would write their code, such that they don't need their call-backs to close over any on-going transaction context.

It is, however, possible for threads to juggle multiple independent transactions – our transactional REST end-point do this – but not through Core API alone. You could do something similar to what the transactional REST end-point does, with suspending and resuming transactions, only more complicated. Say, for instance, if you added a reference-counting scheme to your transaction wrapper, such that every time a transaction context was closed over, the reference increments. Then a commit on a transaction that is referenced elsewhere, would instead decrement the count and suspend the transaction. And "beginning" where a referenced transaction is already closed over, would instead resume the existing transaction.

I imagine such an API could look a bit like this: https://gist.github.com/chrisvest/7646523

And here's an example of how to do transaction suspension and resumption: https://gist.github.com/chrisvest/7504624 -- note that this is using internal and unsupported APIs! In other words, we may arbitrarily change these APIs without notice from version to version... which is why you have to go through first a type-cast to a deprecated interface, and then an opaque DependencyResolver mechanism, to get to this stuff.

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

--

Chris Vest

[ skype: mr.chrisvest, twitter: chvest ]

[joewhite86]

Hey Chris,

the embedding works by using the great node module https://github.com/joeferner/node-java from joeferner. 

It uses C++ to spawn a JVM process. 

The reason i began with it was, that the REST endpoint was too slow (single threaded, serialization) for me on bigger data exchanges over the wire.

The advantage is, that with the embedded driver, the data is marshalled directly to native Javascript objects, wich makes execution much faster in my experience.

Thanks for your great examples, but sadly I think it's not possible to manage the transactions…

From my point of view I would need to assign all Java calls inside a "transaction" function to a specific thread, which would be the most simple solution, if possible.

Another way I see, is to build up some kind of call stack of each function call inside a "transaction" function.

Then pass that stack to Java which executes them in order by reflection or something and let the Java method handle the transaction.

Similar to what the Rest Endpoint does, with Cypher statements.

I need to talk to joeferner about that topic and check if such things are possible.

Thanks for the hints anyway,

Jochen