I think I understand the problem now. Assuming I do, I see two cases:

1) The underlying dataset has locking that is _more_ restrictive that MRSW, in 
which case DatasetGraphWithRecord must expose that locking, lest it break the 
underlying impl.

2) The underlying dataset has locking that is _less_ restrictive that MRSW, in 
which case DatasetGraphWithRecord must eclipse that locking, lest it break 
DatasetGraphWithRecord's impl.

So my task is to adopt some careful meaning for "more" and "less" as used above 
and use it to make DatasetGraphWithRecord's locking more intelligent. I do not 
see anything in Jena that would answer to the purpose, but maybe I am missing 
something. {fingers-crossed}

---
A. Soroka
The University of Virginia Library

On Jul 29, 2015, at 5:04 PM, Andy Seaborne <[email protected]> wrote:

> The lock provided by the underlying dataset may matter.  DatasetGraphs 
> support critical sections.  DatasetGraphWithLock uses critical sections of 
> the underlying dataset.
> 
> I gave an (hypothetical) example where the lock must be more restrictive than 
> ReentrantReadWriteLock (LockMRSW is a ReentrantReadWriteLock + counting 
> support to catch application errors).
> 
> DatasetGraphWithRecord is relying on single-W for its own datastructures.
> 
>       Andy
> 
> On 29/07/15 21:22, [email protected] wrote:
>> I'm not sure I understand this advice-- are you saying that because no 
>> DatasetGraph can be assumed to support MR, there isn't any point in trying 
>> to support MR at the level of DatasetGraphWithRecord? That would seem to 
>> make my whole effort a bit pointless.
>> 
>> Or are you saying that because, in practice, all DatasetGraphs _do_ support 
>> MR, there's no need to enforce it at the level of DatasetGraphWithRecord?
>> 
>> ---
>> A. Soroka
>> The University of Virginia Library
>> 
>> On Jul 29, 2015, at 4:14 PM, Andy Seaborne <[email protected]> wrote:
>> 
>>> On 27/07/15 18:06, [email protected] wrote:
>>>>> Is there some specific reason as to why you override the 
>>>>> DatasetGraphWithLock lock?
>>>> Yes, because DatasetGraphWithLock has no Lock that I could find, and it 
>>>> inherits getLock() from DatasetGraphTrackActive, which just pulls the lock 
>>>> from the wrapped DatasetGraph. I wanted to make sure that a MRSW Lock is 
>>>> in play. But maybe I am misunderstanding the interaction here? (No 
>>>> surprise! {grin})
>>>> 
>>> 
>>> A DatasetGraph provides whatever lock is suitable to meet the contract of 
>>> concurrency [1]
>>> 
>>> Some implementations (there aren't any) may not even be able to support 
>>> true parallel readers (for example, datastructures that they may make 
>>> internal changes even in read operations like moving recently accessed 
>>> items to the top or caching computation needed for read).
>>> 
>>> There aren't any (the rules are R-safe) - locks are always LockMRSW.
>>> 
>>> [1] http://jena.apache.org/documentation/notes/concurrency-howto.html
>>> 
>>>     Andy
>>> 
>> 
> 

Reply via email to