RDF4j with multiple readers, 1 writer getting "SAIL is already locked by: [some other ip]"

[cgokey]

I'm trying to setup RDF4J and using version 5 under tomcat with a native store in AWS. I'm using a fargate service where I have multiple readers and 1 writer. I'm obviously not understanding something about the transactional model because as soon as I issue a sparql update and the writer updates the database, none of my readers can access it, even after the transaction has finished -- I'm getting a "SAIL is already locked by: [some other ip]" error message. Is this not supported through the normal /rdf4j-server/server endpoint provided by rdf4j?

I was hoping that as long as I ONLY had 1 writer making changes to the EFS file system (thus not making concurrent updates) , I could still read with the other processes.

[hmottestad]

Is Fargate running up multiple RDF4J instances that interact with the files on disk? And you've set a rule that only allows Fargate to run up one RDF4J instance for writing, but multiple for reading?

[kenwenzel]

You are right. LmdbStore currently also uses the DirectoryLockManager:

rdf4j/core/sail/lmdb/src/main/java/org/eclipse/rdf4j/sail/lmdb/LmdbStore.java

Line 242 in 311d2d9

dirLock = new DirectoryLockManager(dataDir).lockOrFail();

A code change would be needed to allow concurrent use from multiple processes.
I've not yet thought about accessing the store in this way. Although it should be possible with LMDB's architecture.

[cgokey]

Is it just removing the lock at the directory level or are there most ramifications done in the weeds of making this change?

[kenwenzel]

I'm not sure - sorry. But if you have some time then it would be interesting if you could give it a try.

[kenwenzel]

I've just read that
environments may be opened by multiple processes on the same host:
https://www.symas.com/symas-embedded-database-lmdb

This might be a limitation in combination with AWS Fargate.

[cgokey]

Yes, I looked into this and you are right, lmdb is multi process but not multi machine. I still think the approach will work with Fargate, I will just mdb-copy the files over to the slave during container startup and have my load balancer hit a lambda proxy for any writes to ensure that the readers stay in sync. From reading, it looks like I can do a live copy without having to shutdown the server, so that might work.

[cgokey]

Thanks, yeah I believe back in the days of working in lucene, a delta file was created for incremental additions/updates, so could have multiple readers, so was hoping it worked similar… But I might be remembering things wrong. Looking at some other rdf dbs your page links to, might look into halyard next then… Chris

…

On Sun, Feb 2, 2025 at 1:49 PM kenwenzel ***@***.***> wrote: It may work with the LmdbStore as long as autoGrow is not used. But this mode of operation is completely untested. — Reply to this email directly, view it on GitHub <#5244 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFIEXTSPEXCUA5AQL7LUPVD2NZSFHAVCNFSM6AAAAABWJYGHVKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBTGM3TMOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kenwenzel]

You might get LmdbStore to work in this scenario.

[cgokey]

I'll give it a shot, I'm a bit worried it is still considered "experimental"

[kenwenzel]

Especially the on-disk format might change in the future and we need to improve its fsync behavior (default is to not force any fsyncs).