On Fri, Sep 7, 2012 at 10:34 AM, Joshua TAYLOR <[email protected]> wrote:
> On Fri, Sep 7, 2012 at 9:08 AM, Lebling, David (US SSA)
> <[email protected]> wrote:
>> I have a suite of webservices which use OWL ontologies stored as named 
>> graphs in an SDB database. I also have a set of Java objects that provide a 
>> POJO façade over ontology class instances. These instances import many or 
>> even all of the OWL ontologies, so I have an OntDocumentManager which points 
>> to cached versions of the ontologies.
>>
>> When an ontology changes, I need to update it in the database, then re-cache 
>> it in the OntDocumentManager. During those operations (update ontology graph 
>> in database, update cached version in OntDocumentManager) I am within a 
>> try/finally block that (respectively) is a write lock or a read lock.
>>
>> So a sketch (not the full implementation) of the code for writing and 
>> reading would be:
>>
>> void update(String name, Model newModel) {
>> Model model = SDBFactory.connectNamedModel(store, name);
>> try {
>>                 model.enterCriticalSection(false); // write
>>                 model.removeAll();
>>                 model.add(newModel);
>> }
>> finally {
>>                 model.leaveCriticalSection();
>> }
>> }
>>
>> void cache(OntDocumentManager mgr, String name) {
>>                 Model model = SDBFactory.connectNamedModel(store, name);
>>                 Model cachedModel = createModel(); // this method creates an 
>> OWL_MEM model with the doc mgr as its document manager, etc.
>>                 try {
>>                                 model.enterCriticalSection(true); // read
>>                                 cachedModel.add(model);
>>                 }
>>                 finally {
>>                                 model.leaveCriticalSection();
>> }
>> mgr.addModel(name, cachedModel, true);
>> }
>>
>> What appears to happen is that these critical sections don't appear to 
>> inhibit other users (in my tests I have five) of the SDB database from 
>> modifying the stored graph. Readers of the graphs sometimes end up with 
>> empty graphs. I will sometimes end up with stored graphs that are empty, or 
>> inconsistent in some way that eventually corrupts the underlying tables in 
>> the database, requiring a complete reinitialization. I also get 
>> IllegalThreadState exceptions. Many different exceptions are thrown, with 
>> little obvious consistency.
>>
>> Is critical section only good within a JVM? Do I need to use some sort of 
>> transaction instead?
>
> The "Concurrent access to models" document [1] describes the Lock
> mechanisms that you're using now, but says that they're for the
> "multiple threads in a single JVM" and to use transactions for
> database backed models.  I haven't used SDB (or TDB), so I can't point
> you to the documentation on those systems, but I think those are what
> you need;  hopefully someone else will chime in.

After a bit more Googling, I think you might be interested in the
javadoc pages for TransactionHandler [1] and TransactionHandlerSDB
[2], and Graph#getTransactionHandler() [3].

Hope this helps,
//JT

[1] 
http://jena.apache.org/documentation/javadoc/jena/com/hp/hpl/jena/graph/TransactionHandler.html
[2] 
http://jena.apache.org/documentation/javadoc/sdb/com/hp/hpl/jena/sdb/graph/TransactionHandlerSDB.html
[3] 
http://jena.apache.org/documentation/javadoc/jena/com/hp/hpl/jena/graph/Graph.html#getTransactionHandler()
-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/

Reply via email to