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
