As I read the code, getOntology is a write operation just when it doesn't retrieve a pre-existing (cached) OntModel and must build a new one. If you can be sure that you have always beforehand written the OntModel you are retrieving into the OntDocumentManager using addModel, then I don't think getOntology will do any writing.
On a side note, the locking in the current TIM implementation is pretty minimal and concerned almost entirely with commits. The use of persistent data structures means there are not granular locks inside the data structures, just a few dataset-wide locks that come into play briefly to begin and finish transactions cleanly. I don't think there is any possibility of long-running contention except for multiple threads trying to start WRITE transactions at the same time. (TIM is multiple-reader-and-single-writer.) --- A. Soroka The University of Virginia Library > On Jul 17, 2016, at 8:32 AM, Martynas Jusevičius <marty...@graphity.org> > wrote: > > Thanks Andy. > > All of our code except OntDocumentManager access uses imutable objects, so > I hope to keep lock usage to an absolute minimum. Transactions look like an > overkill at this point. > > So if getOntology() is a write operation, if I wrap only this piece of code > where it is called into a WRITE critical section, wouldn't that be enough? > > I think the docs lack an explanation on which ops are read and which are > write. > > On Sun, 17 Jul 2016 at 12:22, Andy Seaborne <a...@apache.org> wrote: > >> Better: transactions (3.1.0) >> >> http://jena.staging.apache.org/documentation/txn/transactions.html >> >> We now have a fully ACID transactional in-memory graph (TIM) as well as >> TDB. >> >> The "Txn" highlevel API is not in the released codebase. >> >> http://jena.staging.apache.org/documentation/txn/txn.html >> >> Planning now for transactions should make things a lot easier later. >> >> Andy >> >> On 16/07/16 16:03, Martynas Jusevičius wrote: >>> On a second thought, since our code is only reading from the models, it >> is >>> probably easier and safer just to clone the shared model into a >> per-request >>> copy, and keep the code as it is. >> >> If the shared model is only ever read, you can share it. >> >> (getOntology isn't a read operation.) >> >>> >>> Is the following code the fastest way to do it? Is add() expensive? >>> >>> >>> OntModel ontModel = >>> OntDocumentManager.getInstance().getOntology(ontologyURI, ontModelSpec); >>> OntModel clonedModel = ModelFactory.createOntologyModel(ontModelSpec); >>> clonedModel.add(ontModel); >>> >>> >>> On Sat, Jul 16, 2016 at 3:47 PM, Martynas Jusevičius < >> marty...@graphity.org> >>> wrote: >>>> Hey, >>>> >>>> in our webapp, all objects are created per-request, except ontologies >>>> stored in a shared OntDocumentManager, that are accessed like this: >>>> >>>> OntDocumentManager.getInstance().getOntology(ontologyURI, >> ontModelSpec); >>>> >>>> This has caused some ConcurrentModificationExceptions. >>>> I have read the >>>> https://jena.apache.org/documentation/notes/concurrency-howto.html >>>> document, and wanted to check if I get this right. >>>> >>>> Basically, every operation and iterator on a shared OntModel has to be >>>> in a critical section? Even if it's indirect and called on an OntClass >>>> from the OntModel: >>>> >>>> OntModel ontModel = >>>> OntDocumentManager.getInstance().getOntology(ontologyURI, >>>> ontModelSpec); >>>> ontModel.enterCriticalSection(Lock.READ); >>>> try >>>> { >>>> OntClass ontClass = ontModel.getOntClass("http://some/class";); >>>> NodeIterator it = ontClass.listPropertyValues(GC.supportedMode); >>>> try >>>> { >>>> while (it.next) >>>> ... >>>> } >>>> finally >>>> { >>>> it.close(); >>>> } >>>> } >>>> finally >>>> { >>>> model.leaveCriticalSection() ; >>>> } >>>> >>>> Is that correct? >>>> >>>> Martynas >>> >> >>
