Thanks for the teaching lesson on shared locks, which just makes it easier, and obviously makes more sense.
2012/3/30 Christian Grün <christian.gruen@gmail.com>Hi,
yes, I think we should rather go for the lock approach. Still, I'd
> My first idea would be to try and lock the main table of the database,
> `tbl.basex`, via FileChannel.tryLock(). That should be just as effective in
> preventing concurrent access, with the added benefit of leaving no orphaned
> files behind when the BaseX instance isn't terminated gracefully.
prefer to create a separate file for each process accessing the
database; otherwise, we won't know when to unlock the existing files.
I'm sorry -- I don't understand this objection.
flock()-style shared locks are removed automatically as soon as the file handle is closed, even if the file they're held on still exists, and only after the last one of them is removed can an exclusive lock on the same file be granted. Could you explain what you mean by knowing when to unlock the existing files?
(Also, dealing with locks spread across multiple files tends to be, by nature, a bit more prone to race conditions -- often, one has to leverage directory rather than file semantics to do it safely, but even then it's more work across platforms).