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
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...
Hi Max,
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?
Yes, that's what you need to do. You need to create a custom (sub) context for each query.
Feel free to ask for more details, Christian
basex-talk@mailman.uni-konstanz.de