Ontology caching per request?

[Martynas Jusevičius <ma...@graphity.org>]

Hey all,

I'm having a little problem with a trade-off between ontology caching
and consistency.

I'm using JAX-RS resources with default per-request life-cycle (an
object is created for each request). Resource instance reads an
OntModel from ontology file using OntDocumentManager (caching turned
off) and adds some metadata.

That works fine by itself, but at the end of the request processing an
XSLT stylesheet is invoked, which transforms RDF/XML of the resource
to XHTML. It contains some document() function calls that resolve the
URI of the resource ontology mentioned above (say
http://localhost:8080/). The URI resolver also uses OntDocumentManager
and retrieves RDF/XML from the ontology file -- that also works fine.

The only problem with this approach is, that metadata added by the
resource instance gets lost -- XSLT stylesheet doesn't get to see
them.
Since the approach has to be generic, I don't want to add any explicit
contract between the resource and the transformation/resolver (like
resource.getOntModel()). So that leads me to conclude, that I need to
turn the OntDocumentManager caching on so that the stylesheet has
access to the same ontology state as the resource does.

That however leads to another problem -- that OntDocumentManager
caching extends beyond the request life-cycle. That means multiple
resources can access the same OntModel instance causing concurrency
problems, and metadata accumulates in the ontology causing consistency
problems. I'd rather not deal with synchronization, locking etc. But
do I have another choice?

Am I missing some obvious solution here? If the ontology would somehow
be cached "per request" and the transformation would have access to
that, my problem would be solved.

Martynas
graphity.org

Re: Ontology caching per request?

[Martynas Jusevičius <ma...@graphity.org>]

Nevermind -- as usual, I managed to solve this in a different way.

The JAX-RS resource gets injected into the MessageBodyWriter where the
XSLT transformation executes, and the stylesheet gets access to the
final state (including added metadata) of the ontology by referencing
OntModel of the resource.

Martynas
graphity.org

On Fri, Nov 16, 2012 at 3:46 PM, Martynas Jusevičius
<ma...@graphity.org> wrote:
> Hey all,
>
> I'm having a little problem with a trade-off between ontology caching
> and consistency.
>
> I'm using JAX-RS resources with default per-request life-cycle (an
> object is created for each request). Resource instance reads an
> OntModel from ontology file using OntDocumentManager (caching turned
> off) and adds some metadata.
>
> That works fine by itself, but at the end of the request processing an
> XSLT stylesheet is invoked, which transforms RDF/XML of the resource
> to XHTML. It contains some document() function calls that resolve the
> URI of the resource ontology mentioned above (say
> http://localhost:8080/). The URI resolver also uses OntDocumentManager
> and retrieves RDF/XML from the ontology file -- that also works fine.
>
> The only problem with this approach is, that metadata added by the
> resource instance gets lost -- XSLT stylesheet doesn't get to see
> them.
> Since the approach has to be generic, I don't want to add any explicit
> contract between the resource and the transformation/resolver (like
> resource.getOntModel()). So that leads me to conclude, that I need to
> turn the OntDocumentManager caching on so that the stylesheet has
> access to the same ontology state as the resource does.
>
> That however leads to another problem -- that OntDocumentManager
> caching extends beyond the request life-cycle. That means multiple
> resources can access the same OntModel instance causing concurrency
> problems, and metadata accumulates in the ontology causing consistency
> problems. I'd rather not deal with synchronization, locking etc. But
> do I have another choice?
>
> Am I missing some obvious solution here? If the ontology would somehow
> be cached "per request" and the transformation would have access to
> that, my problem would be solved.
>
> Martynas
> graphity.org