I don’t think you need to worry at all, Claude. It’s my fault for being unclear. I was referring, not to what currently is the case, but what _would_ be the case if Jena went in directions that I understood you and Andy to have tossing around recently in speculative sorts of ways.
That is, I was trying to understand how two ideas, neither of which has been formally adopted or is being implemented, would interact if both of them were implemented, just so as to get a better understanding of both. Sorry if I caused any confusion. --- A. Soroka The University of Virginia Library > On Jan 8, 2016, at 3:21 PM, Claude Warren <[email protected]> wrote: > > 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
