Hi. Is there a way to get what Transactional a DatasetGraph is using and specifically what Lock semantics are in force?
As part of a distributed DatasetGraph implementation I have a DatasetGraphTry wrapper which adds Boolean tryBegin(ReadWrite) and as the name suggests it will try to lock the given DatasetGraph and return immediately, i.e. not block. Internally if it acquires the lock it will call the wrapped void begin(ReadWrite) which "should" not block. This is useful because I can round robin the DatasetGraph's which constitute the distribution without blocking. Especially useful as some of the DatasetGraph's are running in other JVM's. Currently I've reverted the mapping to the DatasetGraph class (requires I manually check the Jena code) but I'd like to understand why and possibly make the code neater... To automate the wrapping I pulled the Lock via getLock() and used the class to lookup the appropriate wrapper. But after digging I noticed that the Lock from getLock() doesn't always match the Transactional locking semantics. DatasetGraphInMem getLock() returns org.apache.jena.shared.LockMRSW but internally its Transactional implementation is using org.apache.jena.shared.LockMRPlusSW which is subtly different. This is noticeable because getLock() isn't overridden but inherits from DatasetGraphBase which declares LockMRSW. A TDB backed DatasetGraph masquerades as a; DatasetGraphTransaction DatasetGraphTrackActive DatasetGraphWrapper which wraps the DatasetGraphTDB DatasetGraphTripleQuads DatasetGraphBaseFind DatasetGraphBase where the getLock() returns INFO Thread[main,5,main] [class org.apache.jena.sparql.core.mem.DatasetGraphInMemory] INFO Thread[main,5,main] [class org.apache.jena.shared.LockMRSW] INFO Thread[main,5,main] [class org.apache.jena.tdb.transaction.DatasetGraphTransaction] INFO Thread[main,5,main] [class org.apache.jena.shared.LockMRSW] INFO Thread[main,5,main] [class org.apache.jena.tdb.store.DatasetGraphTDB] INFO Thread[main,5,main] [class org.apache.jena.shared.LockMRSW] Regards Dick.