On 14/01/16 17:14, A. Soroka wrote:
If I understand the example correctly (and that is a big if, because
I am good at missing the point of these things) either it needs both
kinds of locks, or we have to be able to guarantee that all reads and
writes occur inside a transaction and that all transactions have
snapshot isolation and we would need some system of policy for
transactions (which doesn’t seem remotely practical).
Yes - and across the iterator as well.
Whether the iterator sees the DB as at the time of the find() call
(perfect isolation) or concurrent changing (e.g. read committed like
effects) is a design decision.
Now I am trying to reason about two overlaid system of locks. It
seems to me right now that the data locks could still live in the
base data container, that is whatever object is not a view and has
the actual node references in it (in Andy’s proposed possible design
with Dataset as the “foundation” container, that always would be
Dataset) or as Andy wrote, “on triples", and the structure locks
would live in whatever object was used to create them.
But Andy, it seems from your remark (“structure locks (on indexes)”)
that you are saying that structure locks would live in whatever
object has the actual node references in it, or am I misunderstanding
you? Or are you saying that the structure locks would not respect
classes/objects like Model, Graph, etc., but instead would be
associated directly to the data structures that are storing node
references?
Structure locks are a feature of the implementation like java's
"synchronized". "structure locks" serve a different purpose to "data
locks" (the terminology is invented - there is probably a proper set of
terms).
They stop crashes, NPEs and generally corrupting the datastructures, are
datastructure specific but do not care about consistency of the data and
operations on the data from the application, data model, point of view.
What is needed may be influenced by the upper level locking or it might
be that the structure locks are a set of guaranttees to build on.
Java locks are built on "Syncs"
"Syncs" are built on OS features
At the bottom of the OS are spin locks.
The iterator example is particularly nasty because the iterator executes
after the call to find() returns but in the ideal case, returns results
consistent with the data as at the point of the find().
(c.f. concurrent modification exception)
Andy
---
A. Soroka
The University of Virginia Library
On Jan 8, 2016, at 4:20 PM, Andy Seaborne <[email protected]> wrote:
If you want an example to think about ...
Iterator<Triple> iter = graph.find(S,P,O) ;
How does that work in any locking scheme when there may be writers about during
iteration.
Look like it needs needs both data locks (on triples) and structure locks (on
indexes).
Andy
