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