Add transaction support

[Jotschi]

Currently graph.tx() is not implemented.

I'll take a look at this. I wrote a TP3 wrapper for OrientDB 2.1.x that supports transactions but a wrapper is always a bit slower and very ugly ;)

[Jotschi]

Relates to #17

I decided to stick with the way that orientdb currently handles transactions. Other vendors (e.g Neo4j) use an internal threadlocal to get rid of threading and concurrency issues. Unfortunately orientdb Graph and Element classes are not threadsafe and there is no threadlocal (afaik) that deals with concurrency issues. I would like to see a clean way of handling transactions across threads but i'm not sure what orientdb dev intention was on adding this "limitation". Maybe there is a good reason why they decided to do it this way. The only point that i can make out is that by adding this "limitations" no synchronisation code is needed and no side effect can occur when writing code that used orientdb. The downside to this "limitation" is that i often see myself reloading graph elements when switching threads. This makes it sometimes hard to write fast concurrent code when using orientdb.

The Tinkerpop 3.x Transaction interface javadoc states:

It is expected that this interface be implemented by vendors in a {@link ThreadLocal} fashion.
In other words transactions are bound to the current thread, which means that any graph operation
executed by the thread occurs in the context of that transaction and that there may only be one 
thread executing in a single transaction.

Maybe the thread local approach should be reconsidered. I hesitate to write an TP3 implementation for this since (as mentioned before) i'm not sure why threadlocals were avoided.

Sidenote:

OrientDB has two threadlocals within the OrientBaseGraph which i completely don't understand. Maybe you or someone from orientdb could elaborate what the actual usecase for those fields is.

[mpollmeier]

@lvca or @laa, can you enlighten us?

[lvca]

Hi guys, OrientDB does use TL to manage transactions. Actually the database instance is stored inside ODatabaseRecordThreadLocal. The rule is that one database instance can be used by a thread, because database instances are not thread safe.

With BP2.x we added the possibility to share the same OrientGraph instance across threads by using 2 thread local variables. activeGraph contains the current graph instance in thread local, while initializationStack is a stack to allow working with multiple OrientGraph instances by the same thread.

[Jotschi]

@lvca @iaa

I see. So you use this TL to ensure that the graph is only use by the thread from which it was created. It is used as a kind of safeguard is that right?

With BP2.x we added the possibility to share the same OrientGraph instance across threads by using 2 thread local variables.

I assume db.activateOnCurrentThread() is used in combination with those TLs.

I'm not sure whether this a common case but the activateOnCurrentThread() method and the surrounding documentation led me to the assumption that it would be possible to also reuse BP elements such as vertices and edges by invoking db.activateOnCurrentThread() on the db of the current thread. But i learned the hard way that those elements are not threadsafe.

I have never tried this but i assume that by using db.activateOnCurrentThread() it is possible to:

• Create a transaction that covers changes that were made across multiple threads (No concurrent changes of course)
• Reuse a graph instance across multiple threads and thus avoid exhaustion of pooled resources.

Is there any other usecase for activateOnCurrentThread()?