Hi,

Looking at the responses, I think I missed an important technical point: This is actually a web app running in Tomcat.  What this means is that each user is accessing files from a different thread in Tomcat, and the read-only queries are still locking each other out.

I will try the 7.7 developer release.

I've tried both settings on GLOBALLOCK and they don't seem to make any difference.  As for example queries, all of them are of the form : 

for $x in doc('foobar')//*[@foo="bar" and (etc)]
for $y in (select some more)
(repeat as necessary)
return <some useful XML>

The database is only referenced once at the beginning of the query.

Now, what's happening is that as soon as one thread is querying the database, it's locked out for the other threads.  After retrieving the first result, I have to run a new query in a different thread, to retrieve (again, READ ONLY) a bit of referenced data.  The first query is still running when the second one is launched.  But all I get is:

Unable to get tree: Improper use? Potential bug? Your feedback is welcome:
Contact: basex-talk@mailman.uni-konstanz.de
Version: BaseX 7.6
Java: Oracle Corporation, 1.7.0_04-ea
OS: Mac OS X, amd64
Stack Trace:
java.nio.channels.OverlappingFileLockException
sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1017)
org.basex.io.random.TableDiskAccess.lck(TableDiskAccess.java:183)
org.basex.io.random.TableDiskAccess.sharedLock(TableDiskAccess.java:170)
org.basex.io.random.TableDiskAccess.<init>(TableDiskAccess.java:83)
org.basex.data.DiskData.init(DiskData.java:122)
org.basex.data.DiskData.<init>(DiskData.java:92)
org.basex.core.cmd.Open.open(Open.java:70)
org.basex.query.QueryResources.open(QueryResources.java:231)
org.basex.query.QueryResources.doc(QueryResources.java:126)
org.basex.query.func.FNGen.doc(FNGen.java:177)
org.basex.query.func.FNGen.item(FNGen.java:59)
org.basex.query.func.StandardFunc.compile(StandardFunc.java:48)
org.basex.query.path.Path.compile(Path.java:82)
org.basex.query.QueryContext.analyze(QueryContext.java:225)
org.basex.query.QueryContext.compile(QueryContext.java:209)
org.basex.query.QueryProcessor.compile(QueryProcessor.java:66)
org.basex.core.cmd.AQuery.query(AQuery.java:69)
org.basex.core.cmd.XQuery.run(XQuery.java:22)
org.basex.core.Command.run(Command.java:342)
org.basex.core.Command.exec(Command.java:321)
org.basex.core.Command.execute(Command.java:78)
org.basex.core.Command.execute(Command.java:90)
de.tuebingen.uni.sfs.clarin.tundra.tundraweb.BaseXDirectInterface.xquery(BaseXDirectInterface.java:51)

So, there are two threads in one process querying, and the first one very definitely locks out the second.  But it is definitely a locks problem.

So this isn't different process - my mistake - but different threads locking each other out for no reason I can identify.

-- Scott Martens
 
On 2013-04-25, at 10:46 AM, Jens Erat wrote:

There have been some issues with locking too much in 7.6, war did lots of optimizations in 7.7 (available as a developer release). Using either `set queryinfo on` or the GUI will print which databases will get locked. Is there anything surprising you?


XQuery is a very powerful language and it's not always easy to determine which databases to lock. If you're still having issues in 7.7, I'd be glad if you would provide me with some example queries so we can do further optimizations.

Using GLOBALLOCK as proposed by Dirk can help right now if there are problems, but it should be regarded deprecated and could be removed in later versions. The GUI (and only this) still enforces GLOBALLOCK, as we didn't check for possible problems in there yet.

Regards,
Jens

-- 
Jens Erat
tel:+49-151-56961126
xmpp:jabber@jenserat.de         (preferred messenger)
http://www.jenserat.de/conctact (PGP keys, more ways to contact me)
--
Sent from my tablet pc. Sorry for typos - damn those touchscreens. No PGP on this device - I will not be able to read your encrypted message before I'm back on my computer.

Am 25.04.2013 um 10:31 schrieb Dirk Kirsten <dk@basex.org>:

Hello Scott,

this sounds like a bug to me. BaseX 7.6 introduced database locking, but it is disabled for the standalone version as far as I know. This would very much explain the different behaviour in the different versions of BaseX. However, you can disable database locking using the GLOBALLOCK option.

Additionally, you can find out more about the locking in the documentation at http://docs.basex.org/wiki/Transaction_Management

Getting back to your problem, it seems like a misbehaviour to me that something is blocked in your application although you have only read-only queries. Normally, reading queries should not block each other. Maybe you could give us some more information (a SSCCE would be nice) using the QUERYINFO

Cheers,
Dirk


On Thu, Apr 25, 2013 at 9:59 AM, Scott Martens <scott.martens@uni-tuebingen.de> wrote:
Hi all,

I have an application that's embedding BaseX in Java and generates all xqueries internally.  These queries are *always* read-only.  The problem I'm running into is that file locking prevents more than one user from reading the same file at the same time - something that BaseX 7.2 didn't do, but BaseX 7.6 does.

I've tried using the client-server approach to solve the problem, and it works, sort-of.  But it has a number of other problems for the conditions that it's being run under, and the embedded solution was faster and more robust.

It looks to me like the BaseX standalone command line app and basexgui just ignore file-locking, and as long as I'm just using read-only queries, I have no trouble issuing two queries at once on the same database.    Is this true?  And if so, how is it done?  Because this app is doing only read-queries, it's a lot better a solution for me than client-server, but I can't figure out where in the source code the database is being opened and how it's being done in a way that bypasses locks.

Can anyone give me pointers?

-- Scott Martens
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk



--
Dirk Kirsten, BaseX GmbH, http://basex.org
|-- Firmensitz: Blarerstrasse 56, 78462 Konstanz
|-- Registergericht Freiburg, HRB: 708285, Geschäftsführer:
|   Dr. Christian Grün, Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
_______________________________________________
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk