JENA-957
And this is related to the discussion on JENA-624 currently.
DatasetGraphInMemory is a special case where it's lock (which is MR+SW
not MRSW) is used internally. It is not the model lock is part of the
issue here.
We can encourage the use of transactions.
It may be possible to make the lock interact with transactions:
Thought:
We (now) always have a transactional setup even if its only
DatasetGraphWithLock. So a model from a dataset could use the datassets
lock if the lock translated enter/leave into begin/end or begin/commit.
A free-standing retains its own MRSW lock.
The gist example mixes transactional and non-tranactional use.
At L56 it's outside the write transaction so autocommit applies. As the
W transaction never commits, the implicit second W transaction hangs.
The code took a read lock - not that this matters because it is not the
dataset lock -
With locks, if it's a read lock, then write access is not checked - it's
up to the application to behave.
http://jena.apache.org/documentation/notes/concurrency-howto.html
If it were the dataset lock, then in this case "things go wrong" because
the app is manipulating the lock the transaction mechanism is using. I
hope that if L54 was ds.getLock().enterCriticalSection(write) then it
would block. A read lock from the dataset will let the thread through
as it is MR+SW and then the Graph:add complain (??)
Elsewhere, in TDB, with great care, it is possible to MRSW inside a
transaction. The upper level APIs add the ThreadLocal control to keep
the hidden object but there really is an explicit Transaction object
(org.apache.jena.tdb.transaction.Transaction).
Andy
On 30/11/15 18:19, A. Soroka wrote:
I noticed the other day that the ModelCom locking behavior seems completely
independent of the locking behavior of the dataset that may underlie a Model.
I’m a little worried about that with the advent of DatasetGraphInMemory,
because I think the “ergonomics” could be confusing. I have a test case up here:
https://gist.github.com/ajs6f/3e87cd6f78ec3b4e27a1
The problem is that when used without transactions, DatasetGraphInMemory tries
to “do what the user meant” by auto-wrapping ::add or ::delete operations in
transactions. But this leads to a case where a thread can get a model from a
DatasetGraphInMemory-backed dataset, acquire the write lock for that model with
no trouble, but then block trying to add or delete anything from it because the
mutation is blocked by some other thread elsewhere that has the dataset lock.
What would seem less surprising to me would be for the first thread to block
waiting to get the model write lock.
Does this seem too obscure? Is it worth trying to think about how ModelCom
could respect the locking of an underlying Dataset, if one exists?
---
A. Soroka
The University of Virginia Library
