If you are using rules then they are likely to be a significant part of the overhead of accessing the cloned model.

In which case it would make sense to materialize your OntModel as a no-inference OntModel and then copy that whenever you need to. That will mean that if you update your cloned copy you won't see additional inferences but given your mention of option (b) presumably you don't mean to change the data anyway.


Dave

On 17/10/16 20:36, Martynas Jusevičius wrote:
Hey,

I am looking for a way to either
a) clone an OntModel in a performant way
b) make OntModel instance in OntDocumentManager read-only

The use case goes like this: JAX-RS retrieves an OntModel instance
from OntModel manager per each request, adds to it or changes it, and
discards it after the request.

We cannot directly change the OntModel instance in OntDocumentManager,
because that would pollute it with changes from each request and the
size would grow very quickly.

So I went for the easy way out and cloned the OntModel on each
request, like this:

        OntModel ontModel =
OntDocumentManager.getInstance().getOntology(ontologyURI,
ontModelSpec);

        // lock and clone the model to avoid ConcurrentModificationExceptions
        ontModel.enterCriticalSection(Lock.READ);
        try
        {
            Model baseModel =
ModelFactory.createDefaultModel().add(ontModel.getBaseModel());
            OntModel clonedModel =
ModelFactory.createOntologyModel(ontModelSpec, baseModel);
            if (log.isDebugEnabled()) log.debug("Sitemap model size:
{}", clonedModel.size());
            return clonedModel;
        }
        finally
        {
            ontModel.leaveCriticalSection();
        }

That works, but the problem is that cloning using add() performs very
poorly. According to my profiling, this code takes almost a second to
execute with under 6000 statements, spent mostly in hasNext() of
various iterators.

Not sure if it's relevant, but the OntModelSpec uses GenericRuleReasoner.

Is there a faster way or can you maybe suggest a different approach altogether?

Thanks.


Martynas


Reply via email to