We just encountered a stuck lock on a BaseX database. It was during repeated calls to a RESTXQ operation that modifies the database. The operations were working OK, then one returned an error:
[db:lock] Database 'd7c552cc-1f5e-47dc-ba91-37054695aabf' is currently opened by another process.
This error then appeared for any further attempt to update the database, and persisted for several days (although it seems to have cleared now).
It's possible that two updates were being processed concurrently, but they would have been processed by the same Java VM because the RESTXQ server is the only active interface to the database.
We have seen this error before, but it's difficult to reproduce.
Do you know how this might have happened? And is there a procedure for clearing down an erroneous database lock if it happens?
We are running BaseX version 9.1.2.
Thanks,
Martin Iggulden Screen Systems Martin Iggulden | Software Engineer | SCREEN Main Line : +44 1473 831700 | Direct Dial: +44 1473 831700 Fax : +44 1473 830078 Martin.Iggulden@screensystems.tvmailto:Martin.Iggulden@screensystems.tv
Visit us at Broadcast Asia 18-20th June 2019, Suntec Singapore, stand 6J4-02
[http://www.subtitling.com]http://www.subtitling.com/ [https://www.linkedin.com/company/screen-subtitling-systems-ltd] https://www.linkedin.com/company/screen-subtitling-systems-ltd [https://www.youtube.com/channel/Screen Subtitling Systems] https://www.youtube.com/channel/UCBp2nyUeNbIFz9cD66Ym3AQ [https://twitter.com/ScreenSystems] https://twitter.com/ScreenSystems
[cid:SS2979-sasquatch-final-logos_landscape-logo-w236-h56_0717b6a0-e87e-466e-ba39-e63542a11eee.jpg]https://mysasquatch.info P Before printing, think about the environment
This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
Hi Martin,
This error may happen if (1) two different instances of basex try to open/update the very same database. As BaseX uses standard JVM functionality to acquire the Lock it is very likely that indeed to different processes tried to access the very same file.
Maybe there is some kind of shared database between your instances that you are trying to access?
Best from Konstanz
Michael
Am 10.05.2019 um 09:17 schrieb Martin Iggulden Martin.Iggulden@screensystems.tv:
the same Java VM because the RESTXQ server is the only active interface to the database.
We have seen this error before, but it’s difficult to reproduce.
Do you know how this might have happened? And is there a procedure for clearing down an erroneous database lock if it happens?
We are running BaseX version 9.1.2.
Hi Michael,
Thanks for your feedback. I’m pretty sure that the database is only accessible to a single JVM, but I’ll check it again to be 100% sure. Is there any other possible explanation? I don’t think we’re doing anything too complicated…
In the meantime, it would be great if there was a way to rectify the problem if it happens.
Thanks,
Martin Iggulden Screen Systems
Martin Iggulden | Software Engineer | SCREEN Main Line : +44 1473 831700 | Direct Dial: +44 1473 831700 Fax : +44 1473 830078 Martin.Iggulden@screensystems.tvmailto:Martin.Iggulden@screensystems.tv
Visit us at Broadcast Asia 18-20th June 2019, Suntec Singapore, stand 6J4-02
[http://www.subtitling.com]http://www.subtitling.com/ [https://www.linkedin.com/company/screen-subtitling-systems-ltd] https://www.linkedin.com/company/screen-subtitling-systems-ltd [https://www.youtube.com/channel/Screen Subtitling Systems] https://www.youtube.com/channel/UCBp2nyUeNbIFz9cD66Ym3AQ [https://twitter.com/ScreenSystems] https://twitter.com/ScreenSystems
[cid:SS2979-sasquatch-final-logos_landscape-logo-w236-h56_0717b6a0-e87e-466e-ba39-e63542a11eee.jpg]https://mysasquatch.info P Before printing, think about the environment From: Michael Seiferle [mailto:ms@basex.org] Sent: 13 May 2019 10:53 To: Martin Iggulden Martin.Iggulden@screensystems.tv Cc: basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Database lock during RESTXQ operation
Hi Martin,
This error may happen if (1) two different instances of basex try to open/update the very same database. As BaseX uses standard JVM functionality to acquire the Lock it is very likely that indeed to different processes tried to access the very same file.
Maybe there is some kind of shared database between your instances that you are trying to access?
Best from Konstanz
Michael
Am 10.05.2019 um 09:17 schrieb Martin Iggulden <Martin.Iggulden@screensystems.tvmailto:Martin.Iggulden@screensystems.tv>:
the same Java VM because the RESTXQ server is the only active interface to the database.
We have seen this error before, but it’s difficult to reproduce.
Do you know how this might have happened? And is there a procedure for clearing down an erroneous database lock if it happens?
We are running BaseX version 9.1.2.
This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
Hi Martin,
hard to tell what went wrong then without looking at your setup. Did it happen again or has it been a one-time issue?
Best Michael
-- Michael Seiferle, BaseX GmbH, http://www.basexgmbh.de |-- Firmensitz: Obere Laube 73, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Tel: +49 7531 916 82 77
Am 15.05.2019 um 08:40 schrieb Martin Iggulden Martin.Iggulden@screensystems.tv:
Thanks for your feedback. I’m pretty sure that the database is only accessible to a single JVM, but I’ll check it again to be 100% sure. Is there any other possible explanation? I don’t think we’re doing anything too complicated…
Hi Michael,
Our application runs in a BaseX container on Azure, with only the RESTXQ interface exposed. We briefly experimented on our test system with scaling out the container to multiple instances with the same database, and got a lot of errors like this. Not a problem, because we understand that’s not supported.
However, this happened once on our production system, which is single instance. It occurred during two rapid edits, which could have arrived very close to each other on the RESTXQ interface, hence concurrent execution, but in the same JVM.
We’re monitoring it, but haven’t had any further reports. We’d like to have a procedure for clearing these locks in case it happens in production with real customer data, as the customer would be “frozen out” and unable to edit.
Thanks,
Martin Iggulden Screen Systems
Martin Iggulden | Software Engineer | SCREEN Main Line : +44 1473 831700 | Direct Dial: +44 1473 831700 Fax : +44 1473 830078 Martin.Iggulden@screensystems.tvmailto:Martin.Iggulden@screensystems.tv
Visit us at Broadcast Asia 18-20th June 2019, Suntec Singapore, stand 6J4-02
[http://www.subtitling.com]http://www.subtitling.com/ [https://www.linkedin.com/company/screen-subtitling-systems-ltd] https://www.linkedin.com/company/screen-subtitling-systems-ltd [https://www.youtube.com/channel/Screen Subtitling Systems] https://www.youtube.com/channel/UCBp2nyUeNbIFz9cD66Ym3AQ [https://twitter.com/ScreenSystems] https://twitter.com/ScreenSystems
[cid:SS2979-sasquatch-final-logos_landscape-logo-w236-h56_0717b6a0-e87e-466e-ba39-e63542a11eee.jpg]https://mysasquatch.info P Before printing, think about the environment From: Michael Seiferle [mailto:ms@basex.org] Sent: 15 May 2019 10:30 To: Martin Iggulden Martin.Iggulden@screensystems.tv Cc: basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Database lock during RESTXQ operation
Hi Martin,
hard to tell what went wrong then without looking at your setup. Did it happen again or has it been a one-time issue?
Best Michael
-- Michael Seiferle, BaseX GmbH, http://www.basexgmbh.de |-- Firmensitz: Obere Laube 73, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Tel: +49 7531 916 82 77
Am 15.05.2019 um 08:40 schrieb Martin Iggulden <Martin.Iggulden@screensystems.tvmailto:Martin.Iggulden@screensystems.tv>:
Thanks for your feedback. I’m pretty sure that the database is only accessible to a single JVM, but I’ll check it again to be 100% sure. Is there any other possible explanation? I don’t think we’re doing anything too complicated…
This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
basex-talk@mailman.uni-konstanz.de
-
Martin Iggulden -
Michael Seiferle