Understanding the DBLocking mechanism
Monday, 14 July 2014 · 3 messages · last reply 15 Jul 2014
MG
Maximilian Gärber14 Jul 2014 16:05 #
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/ReentrantLock.html http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html
MG
Maximilian Gärber14 Jul 2014 16:32 #
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 at uni-konstanz.de>:
Quoted text · Maximilian Gärber · 43 lines
> 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 at jenserat.de > [jabber]: xmpp:jabber at 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 at 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/ReentrantLock.html >> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html >
CG
Christian Grün15 Jul 2014 12:17 #
Hi Max,
Quoted text · Maximilian Gärber · 3 lines
> 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
Written for BaseX 7.9. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery