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 <[email protected]> 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
