Claude, can I ask you to write more about `engine` in your outline below? Are you proposing some global entity that manages locks across more than one dataset? Or are you saying that something would be needed to coordinate between graphs, models, and datasets that might have dependencies amongst themselves, because right now, those different types can have independent state (instead of all of them being views on datasets, as in Andy’s idea)? In either case, it seems a little to me like the role of `engine` could be filled by a (as-yet-non-existent) Transaction object, if I am understanding correctly in either case.
I definitely would think you would want to acquire locking context from the dataset/model/graph with which you are working (or a view thereon). That would allow for optimizations. --- A. Soroka The University of Virginia Library > On Jan 9, 2016, at 8:27 AM, Claude Warren <[email protected]> wrote: > > structure locks (on indexes) are implementation specific, right? > > I think this means that we need a way to register listeners that act > somewhat like participants in a XA locking session. > > So we have something like > > request for lock received. > lock the triples in the internal engine > check each lock listener and lock the triples in the listener. > if any listener can not lock undo the locks thus far and abort. > otherwise return lock success. > > Perhaps a LockListener interface like: > > boolean exclusiveLock( Triple ... ) > void exclusiveUnlock( Triple ... ) > boolean sharedLock( Triple ... ) > void sharedUnlock( Triple ... ) > > where Triple is any valid triple pattern like {<Foo> ANY ANY}, though > perhaps Quads would be a better choice. > > Another possibility is that the engine lock call would return an object > that could then be used as the context for the lock listener. > > LockContext ctxt = engine.lock( Triple ... ); > for (LockListener listener : listeners ) > { > listener.exclusiveLock( ctxt, Triple ... ); > } > > The above example is missing all the "Back out the locks on failure" code. > > Perhaps the LockContext should be retrieved from the Graph, Model or > Dataset so we have > > LockContext ctxt = dataset.createLockContext() > > engine.WriteLock( ctxt, Triple .... ) > > LockContext would have a getListeners() method to provide a set of > listeners so that the engine could call the appropriate listener checks. > > > Thoughts? > > Claude > > > On Fri, Jan 8, 2016 at 9: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 >> > > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren
