[Mulgara-general] problem with Session.modelExists(URI uri)

Andrae Muys andrae at netymon.com
Fri Nov 30 07:28:37 UTC 2007


On 30/11/2007, at 4:05 PM, Paul Gearon wrote:

> The real problem here is the use of the JRDF interface.  The code  
> behind this interface was using some bad processes which violated  
> ACID requirements.  As a result of the transaction work that Andrae  
> did, he had to break this interface.  He intends to get it working  
> again, but it has not been a priority lately.

Actually JRDF has been 'fixed' for some time now.  Although that  
comes with some caveats.  First, client-side JRDF has never been  
fully functional, it has always had trouble because JRDF requires the  
ability to round-trip Blank-Nodes - and supporting that requires  
providing the JRDF client-side interface with greater control over  
transactions then we have supported.  Also not having the time to do  
a full code-inspection myself, I have relied on the regression-tests  
provided by Andrew to check that the new transaction code hasn't  
broken JRDF - any gaps in the test coverage here may result in  
changes in behaviour.

OTOH, a closer look at this test case suggests that the bug may not  
have anything to do with JRDF at all - while there are casts to  
various JRDF interfaces here, neither factory.close() nor  
session.modelExists() are calls to the JRDF interface.  Rather these  
are direct calls to the Session interface, and hence  
DatabaseSession.  Consequently I can't see any reason why this code  
wouldn't behave in exactly the same way if the call to  
factory.newJRDFSession() were replace with a call to  
factory.newSession().

In fact I just managed to reproduce the bug here, and I've been able  
to confirm this bug has nothing to do with JRDF.  It looks like the  
call to factory.close() has managed to close the StringPool somehow -  
I'm interested in finding out how that happened.

> In the meantime, there isn't anything that JRDF could do that TQL  
> can't do (in fact, JRDF could be implemented as a wrapper around  
> TQL).  I recommend using that instead - at least for now.

This isn't entirely correct.  JRDF can do one thing that iTQL cannot  
and that is to round-trip a Blank-node retrieved from a previous  
query.  Of course this is not a legitimate thing to do unless you can  
guarantee you stay within a single transaction - and indeed *all* of  
the problems we have had with JRDF stem from this single  
requirement.  However if blank-node round-tripping isn't required by  
your application, then iTQL can do everything you need - although if  
you're replacing JRDF I personally prefer to build directly on  
Session rather than iTQL.

Also, I'm looking at the code below and I don't see a 'temporary  
workaround', as far as I am concerned this is a perfectly clean and  
legitimate fix.  If there are not objections I'll check this into  
trunk tomorrow.

Andrae

>> }Index: src/jar/resolver/java/org/mulgara/resolver/ 
>> ModelExistsOperation.java
>> ===================================================================
>> --- src/jar/resolver/java/org/mulgara/resolver/ 
>> ModelExistsOperation.java	(revision 501)
>> +++ src/jar/resolver/java/org/mulgara/resolver/ 
>> ModelExistsOperation.java	(working copy)
>> @@ -66,10 +66,17 @@
>>                       ResolverSessionFactory resolverSessionFactory,
>>                       DatabaseMetadata       metadata) throws  
>> Exception
>>   {
>> -    long model = systemResolver.lookupPersistent(new  
>> URIReferenceImpl(
>> +    try {
>> +      long model = systemResolver.lookupPersistent(new  
>> URIReferenceImpl(
>>         modelURI));
>> -
>> -    result = systemResolver.modelExists(model);
>> +      result = systemResolver.modelExists(model);
>> +      // Temporary workaround: if modelURI is not known, the  
>> localize attempt
>> +      // fails and returns an exception. However, in this case,  
>> we should return
>> +      // false. See:
>> +      // http://mulgara.org/pipermail/mulgara-general/2007- 
>> October/000195.html
>> +    } catch(LocalizeException le) {
>> +        result = false;
>> +    }
>>   }


-- 
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd





More information about the Mulgara-general mailing list