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.

Reply via email to