hmmmm... I'm missing something here. I thought Datasets were ontop of Models. if Datasets are the fundamental object then I need to get an implementation of permisisons on datasets. Dang, and my plate is rather full at the moment. :(
I thought the layers went Dataset Model Graph Claude On Fri, Jan 8, 2016 at 5:08 PM, A. Soroka <[email protected]> wrote: > I’d like to try to kick this thread around a bit, hopefully in a helpful > way. I’ve been thinking about an idea that Andy has tossed around a bit: > that Models, Graphs, etc. could just be views on underlying Datasets. I’ve > been trying to understand how this would work in connection with Claude’s > ideas about fine-grained, possibly nested locking. If I understand both > ideas correctly, it seems to me that the following result would hold in a > Jena that takes up both: > > Locks on any kind of object other than an underlying Dataset would be > “views” (so to speak) over locks on the underlying Dataset. This would > ensure that locks made via a view are visible to other views and the > underlying Dataset and that locks made on the underlying Dataset are > visible to all views. > > Does that claim seem reasonable (especially to Andy and Claude)? > > --- > A. Soroka > The University of Virginia Library > > > On Jan 3, 2016, at 8:45 AM, Claude Warren <[email protected]> wrote: > > > > Andy, > > I have not read trough the links in your last post yet but thought I > might > > answer the questions you posed as per my thoughts prior to reading those > > posts. (concepts subject to change) > > > > > >> As I understand it, the application is now involved to describe the part > >> of the graph to lock. Is that right? > >> > > > > That was my thought yes. I was only looking at how to lock for write. I > > had not considered read locking, though I expected it would work like the > > current lock does in the sense that read locks block write locks. > Though I > > suppose it might be possible in some situations to specify what the > thread > > was going to read. > > > > > >> > >> To check here - locks are held for a critical section (as current > design)? > >> Not a single API call? Something else? > >> > >> The permissions system is per API call but then permissions are not > >> changing like data is on a live system. > >> > >> > > I was thinking that they would be held for a critical section only as > > currently done. > > > > I agree there are significant distinctions between the permissions and > > locking as the permissions data does not change within a single call. > > > > > > > >> > >> Does failure mean an exception or waiting? > >> > >> > > My thought was failure/exception. As you point out waiting leads to > > deadlock issues. However, the decision to wait or fail could be > > implemented outside of the engine that determines if the lock can be > > granted. So it could be a plugable decision. For the first cut I would > > simply implement failure. > > > > But looking at the enterCriticalSection() code I see that it does not > allow > > failure, but that there is a mention of an error if a read lock is > promoted > > to a write lock. I am unsure how to handle this case. I think that a > lock > > failure exception may be needed. > > > > A possible solution is to delay and retry with a retry time out/limit > > before throwing a timeout type exception. This area needs work. > > > > > >> > >> These tests themselves have to be done by some synchronized code becaue > >> there are multiple tests while other threads may be changing things at > the > >> same time. > >> > >> > > agreed. The internals of the locking code need synchronization. > > > > > >> How far back are you going to wind back to? In a transaction system > either > >> the transaction is aborted (so all the way back); some system retry > (i.e. > >> rerun application code). > >> > > > > I had assumed that the application would lock all the triples it needed > at > > the start of the lock. this is supposed to be a small critical section. > > However, I can see how nested class method calls might cause multiple > locks. > > > > So lets assume code execution like: > > {noformat} > > { > > try { > > Lock( <foo ANY ANY> ) > > // some processing here > > try { > > Lock( <bar ANY ANY >) > > // some processing here > > } catch (LockFailedException e) { > > // handle "bar" lock failure > > } finally { > > Unlock( <bar ANY ANY > ) > > } > > } catch (LockFailedException e ) { > > // handle "foo" lock failure > > } finally { > > Unlock( <foo, ANY ANY > ) > > } > > // for grins ;) > > Unlock(); // release all held locks. > > } > > > > {noformat} > > > > The partial solution is to require lock ordering - locks must be acquired > >> in the same order and same class - and for a sequence of operations, not > >> just a single access. > >> > >> The application is now involved - this is a specialized programming > model > >> for the ability to have multiple writers. > >> > > > > If we consider the lock request to be a set of patterns then then the > lock > > itself holds a set of patterns. For example Lock( <foo ANY ANY> <bar ANY > > ANY ) would create a lock holding the fooAny and barAny triples. > > Subsequently calling Lock( <baz, ANY ANY> ) would result in the set: <foo > > ANY ANY> <bar ANY ANY> <baz ANY ANY>. calling Unlock( <bar ANY ANY> ) > > would result in the set: <foo ANY ANY> <bar ANY ANY>. > > > > So locks for a single thread do not need to be released in the order they > > were acquired. But all the locks must be released when the critical > > section exits. > > > > > > > >> It would be a good thing to have as an additional choice of graph > (ideally > >> dataset) implementation. A multi-writer dataset, then just make graph > >> views of the dataset, would great to have. > >> > >> Is it easy to build an experimental version using the permissions code? > >> > >> Andy > >> > >> > > I'm not sure how much of the permissions code would be applicable. It > uses > > dynamic proxies to intercept graph and model (and assorted helper > classes) > > method calls. > > > > I think the locking engine is more likely like a query engine > > implementation having to do pattern matching on sets of triples. > > > > I think that the starting place may be to extend the Lock interface to > > include: > > enterCriticalSection( triple .... ); // establish a lock for the triples > > Graph getLockPattern(); // get the lock pattern > > void lock( triple ... ); // add to lock pattern > > void unlock( triple ...); // remove from lock pattern > > void unlock(); // remove all locks > > > > It might make more sense to put the last 4 into a separate interface and > > have a method to return an instance of that interface. Something like: > > > > LockHoldings getLocks(); > > > > > > It seems to me the complex part is going to be determining if any thread > > already has the a lock on the object from the patterns. I can dig into > > that to see if I can get an early prototype of lock tracking. > > > > Claude > > > > -- > > I like: Like Like - The likeliest place on the web > > <http://like-like.xenei.com> > > LinkedIn: http://www.linkedin.com/in/claudewarren > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
