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).
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? --- 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
