On 03/08/15 17:13, [email protected] wrote:
I've made some emendations to (hopefully) fix this problem. In order to so do,
I added a method to Lock itself to report the quality of an instance, simply as
an enumeration. I had hoped to avoid touching any of the extant code, but
because Lock is a public type that can be instantiated by anyone, I just can't
see how to resolve this problem without some way for a Lock to categorize
itself independently of the type system's inheritance.
Feedback welcome!
A few things occur to me:
1/
The transaction log is for supporting abort for writers only. Nothing
needs to be done in DatasetGraphWithRecord for readers.
DatasetGraphWithLock does what's needed. So you don't even need to
startRecording for a READ (and the commit clear - _end always aborts is
an interesting way to do it!).
2/
Datasets that provide support for MW cases and don't provide
transactions seem rather unlikely so may be document what kind of
DatasetGraph is being supported by DatasetGraphWithRecord then just use
the underlying lock..
It's not just a case of using ConcurrentHashMap, say, as likely there
would be multiple of them for different indexes and that would give
weird consistency issues as different parts get updated safely with
respect to part of the datastructure but it will be visibly different
depending on what the reader uses. So I think MW will have additional
coordination.
3/
There are two thing to protect in DatasetGraphWithRecord : the
underlying dataset and transaction log for supporting abort for writers
only. They can have separate mechanisms. Use the dataset lock for the
DatasetGraph actions and make the transaction undo log operations be
safe by other means.
.. hmm ... the order of entries in the log may matter so true parallel
MW looks increasing hard to deal with anyway. Document and not worry
for now?
Andy
---
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
