Database lock during RESTXQ operation
Friday, 10 May 2019 · 5 messages · last reply 17 May 2019
MI
Martin Iggulden10 May 2019 09:17 #
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 at screensystems.tv<mailto:Martin.Iggulden at 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
MS
Michael Seiferle13 May 2019 11:52 #
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
Quoted text · Martin Iggulden · 10 lines
> Am 10.05.2019 um 09:17 schrieb Martin Iggulden <Martin.Iggulden at 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. >
MI
Martin Iggulden15 May 2019 08:40 #
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 at screensystems.tv<mailto:Martin.Iggulden at 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
Quoted text · Michael Seiferle · 17 lines
From: Michael Seiferle [mailto:ms at basex.org] Sent: 13 May 2019 10:53 To: Martin Iggulden <Martin.Iggulden at screensystems.tv> Cc: basex-talk at 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 at screensystems.tv<mailto:Martin.Iggulden at 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
MS
Michael Seiferle15 May 2019 11:30 #
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
Quoted text · Martin Iggulden · 5 lines
> Am 15.05.2019 um 08:40 schrieb Martin Iggulden <Martin.Iggulden at 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… >
MI
Martin Iggulden17 May 2019 08:41 #
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 at screensystems.tv<mailto:Martin.Iggulden at 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
Quoted text · Michael Seiferle · 19 lines
From: Michael Seiferle [mailto:ms at basex.org] Sent: 15 May 2019 10:30 To: Martin Iggulden <Martin.Iggulden at screensystems.tv> Cc: basex-talk at 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 at screensystems.tv<mailto:Martin.Iggulden at 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
Written for BaseX 9.2. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery