I think it is a worthwhile idea. Given that you are still having to get a global lock to get a triple lock, isn't there still a scaling limit on the global lock?
I think a lot about the things that made the relational database approach so successful and certainly one thing is that row-level locking corresponds well to real-life access patterns. On Sat, Jan 2, 2016 at 9:18 AM, Claude Warren <[email protected]> wrote: > Currently most Jena implementations use a multiple read one write > solution. However, I think that it is possible (with minimal work) do > provide a solution that would allow for multiple writers by using lower > level locks. > > I take inspiration from the Privileges code. That code allows privileges > to be determined down to the triple level. Basically it does the following > {noformat} > start > | > v > may user perform operation on graph? → (no) (restrict) > | > v > (yes) > may user perform operation on any triple in graph → (yes) (allow) > | > v > (no) > may user perform operation on the specific triple in graph → (yes) (allow) > | > v > (no) (restrict) > {noformat} > > My thought is that the locking may work much the same way. Once one thread > has the objects locked the any other thread may not lock the object. The > process would be something like: > > Graph locking would require exclusive lock or non-exclusive lock. If the > entire graph were to be locked for writing (as in the current system) then > the request would be for an exclusive write-lock on the graph. Once an > exclusive write lock has been established no other write lock may be > applied to the graph or any of its triples by any other thread. > > If a thread only wanted to lock part of the graph, for example all triples > matching <u:foo ANY ANY>, the thread would first acquire a non-exclusive > write lock on the graph. It would then acquire an exclusive write lock on > all triples matching <u:foo ANY ANY>. Once that triple match lock was > acquired no other thread would be able to lock any triple who's subject was > u:foo. > > The lock request would need to contain the graph name and (in the case of a > partial graph lock) a set of triple patterns to lock. The flow for the > lock would be something like: > > {noformat} > start > | > v > does the thread hold an exclusive graph lock → (yes) (success) > | > v > (no) > does the thread want an exclusive graph lock → (yes) (go to ex graph lock) > | > v > (no) > does the thread hold a non-exclusive graph lock → (no) (go to nonex graph > lock) > | > v > (yes) (lbl:lock acquired) > can the thread acquire all the triple locks → (yes) (success) > | > v > (no) (failure) > > > (lbl: nonex graph lock) > does any thread hold an exclusive graph lock → (yes) (failure) > | > v > (no) > acquire non-exclusive graph lock > (goto lock acquired) > > > (lbl: ex graph lock) > does any thread hold an exclusive graph lock → (yes) (failure) > | > v > (no) > does any thread hold a non-exclusive graph lock → (yes) (failure) > | > v > (no) > acquire exclusive graph lock > (success) > > {noformat} > > The permissions system uses an abstract engine to determine if the user has > access to the triples. For the locking mechanism the system needs to track > graph locks and triple patterns locked. If a new request for a triple > pattern matches any existing (already locked) pattern the lock request > fails. > > The simple releaseLock() will release all locks the thread holds. > > Note that the locking system does not check the graph being locked to see > if the items exist in the graph it is simply tracking patterns of locks and > determining if there are any conflicts between the patterns. > > Because this process can duplicate the current locking strategy it can be > used as a drop in replacement in the current code. So current code would > continue to operate as it does currently but future development could be > more sensitive to locking named graphs, and partial updates to provide > multi-thread updates. > > Thoughts? > Claude > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren > -- Paul Houle *Applying Schemas for Natural Language Processing, Distributed Systems, Classification and Text Mining and Data Lakes* (607) 539 6254 paul.houle on Skype [email protected] :BaseKB -- Query Freebase Data With SPARQL http://basekb.com/gold/ Legal Entity Identifier Lookup https://legalentityidentifier.info/lei/lookup/ <http://legalentityidentifier.info/lei/lookup/> Join our Data Lakes group on LinkedIn https://www.linkedin.com/grp/home?gid=8267275
