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.tv

Visit us at
Broadcast Asia 18-20th June 2019, Suntec Singapore, stand 6J4-02

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.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…