Am Donnerstag, 29. März 2012, 16:23:12 schrieb Charles Duffy:
Howdy --
I recently had an update run via the REST interface fail due to the database being "opened by another client". This would be unsurprising were it taking place on a workstation where a concurrent process such as basexgui might have been running, but the host in question was a server, with its basexhttp instance controlled by system init scripts, running as a dedicated user, and otherwise unlikely to be interfered with by a separate process. There are, however, multiple concurrent REST clients using that same HTTP server.
As basexhttp should be the only service directly accessing the underlying database on this host, this surprises me -- my expectation is that the transaction monitor would defer any execution of an update until a full lock could be grabbed, preventing it from interfering with other read or update actions happening within the same process.
Is this expectation valid? If not, what do I need to do to be able to apply updates to a database with minimal disruption to readers?
hm, actually I think it's a bug: if a running REST request is interrupted, while another one is trying to acquire a write lock on the same database, then the database is left open. I can reproduce it as follows:
$ curl -i -X GET "admin:admin@localhost:8984/rest/testdb?query=(1%20to%2010000000000000)"
While the first query is running start the following:
$ curl -i -X PUT -T "test.xml" "admin:admin@localhost:8984/rest/testdb"
The PUT request waits, which is ok, but if the GET request is interrupted, the PUT receives:
"Database 'testdb' is currently opened by another client."
Subsequent attempts to execute the PUT request fail with the same error.
Regards, Dimitar