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
