On 17/07/16 13:54, Martynas Jusevičius wrote:
But then again, I cannot lock what I don't have: locks work on models, and
I only get OntModel instance when getOntology() is called.
Maybe synchronized is the solution here?
You can lock how you like - the Jena lock code is helper code, to
promote proper critical sections and make app writers aware that
concurrency matters. It is not fundamental in any way - it's normally a
a java ReentrantReadWriteLock with some tracking code to catch
programming errors.
If you are observing actual exceptions, it would be good to get the
traces. The caches are based on Guava's thread safe cache code although
(legacy) the cache setter is outside the get-or-fill operation. From
reading the code, it looks like the worse that can happen is to read a
remote resource more than once. But it's possible I've missed what
happening.
As a general system point : notional read operations that internally
cache should make themselves multi-thread-read safe.
Andy
On Sun, 17 Jul 2016 at 15:32, 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
