[Pellet-users] Concurrent access to Pellet

[Paolo Bussotti]

Hi everybody, and excuse me I've send to you two mails in few days.

With reference to the Pellet Faq about concurrent use of Pellet, what happens if I use a unique binary semaphore (both for reading and writing) in such a way that 
no two queries (nor assertions) can be done concurrently by different threads?
I think (please correct me if I'm wrong) that, such a "collaborative synchronisation" which of course depends strongly on the correct behaviours of threads as for getting and then releasing locks, should not create problems to the knowledgebase processing. 
In my system the access to Pellet is from a Jena pellet-backed ontmodel, and so, when writing, I always have to prepare the OntModel or better, the PelletInfGraph, for loading the model contents and then accessing the KB services (e.g. consistency).
I'm not working with incremental consistency (PelletOptions.USE_INCREMENTAL_CONSISTENCY=false)  and I have set lazyconsistency=false. So when I invoke prepare() on the PelletInfGraph after a change, the method brings me to invoke kb.isConsistent() which doesn't return immediately because of the change I've made before (i.e. isConsistencyDone()=false) so that the fact that "canUseIncConsistency" is false brings me to the call kb.prepare(); 
As mentioned before, also as for queries no two threads are allowed to work concurrently, and the resultSet iterator is only used after the query, whithin the same lock-owning session.
I ask you please if it is correct, and thank you in advance.
Best Regards,
        Paolo Bussotti           
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owldl.com/pipermail/pellet-users/attachments/20080428/947b8789/attachment.htm