Hi, ok - guess I need to dig deeper into constraints of a "two phase commit" then... So, when using the core-API in embedded mode, the preferred way would be to create a new Thread per query - somewhat like the ClientListener does in server mode? Regards, Max 2014-07-14 16:09 GMT+02:00 Jens Erat <jens.erat@uni-konstanz.de>:

Hi Max,

BaseX uses strict two phase locking to prevent deadlocks, therefor it is not allowed to fetch any locks after releasing the first one.

Enhancing locking (and relaxing the conditions) is still considered, but there is no estimate when it will be available (and what kind of concurrency control).

Regards, Jens

-- Jens Erat

[phone]: tel:+49-151-56961126 [mail]: mailto:email@jenserat.de [jabber]: xmpp:jabber@jenserat.de [web]: http://www.jenserat.de

PGP: 350E D9B6 9ADC 2DED F5F2 8549 CBC2 613C D745 722B

Am 14.07.2014 um 16:05 schrieb Maximilian Gärber <mgaerber@arcor.de>:

...

Hi,

while trying to understand the locking internals I stumbled over DBLocking.java#L106 (in core) which throws an Exception when the same thread tries to get a lock again.

The Java documentation states that ReentrantReadWriteLock should be able to handle this [1], are there any extra-conditions that make this neccessary?

Regards,

Max

[1] "The method will return immediately if the current thread already owns the lock." http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Reentran... http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/Reentran...