On 17/05/11 17:25, Frank Budinsky wrote:
Thanks Andy, I think that explains it. I have a couple of unprotected
TDB.sync() calls in my code. From what you're saying, I presume that any
calls I make to TDB.sync() also need to be wrapped in a lock like this:
fResourceDataset.getLock().enterCriticalSection(Lock./WRITE/);
*try*{
TDB./sync/(fResourceDataset);
} *finally*{ fResourceDataset.getLock().leaveCriticalSection(); }
Is that right?
Yes
Andy
Thanks,
Frank.
Inactive hide details for Andy Seaborne ---05/17/2011 11:14:05 AM---On
17/05/11 14:53, Frank Budinsky wrote: >Andy Seaborne ---05/17/2011
11:14:05 AM---On 17/05/11 14:53, Frank Budinsky wrote: >
From:
Andy Seaborne <[email protected]>
To:
[email protected]
Date:
05/17/2011 11:14 AM
Subject:
Re: Concurrency problem
------------------------------------------------------------------------
On 17/05/11 14:53, Frank Budinsky wrote:
>
>
> Hi guys,
Hi Frank,
Your code looks OK but the error message implies there is another thread
about (it looks like the other thread is doing a write (includes sync) -
the stacktrace shows the code is doing a read at this point).
TDB throws ConcurrentModificationException as a checking operation.
it's not connected with locks directly but exists to check locks are
being used for MRSW. So "Reader = 1" is this thread, and "Writer = 1"
is something else.
Andy
>
> I'm getting the following exception sometimes:
>
> java.util.ConcurrentModificationException: Reader = 1, Writer = 1
> at com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.policyError
> (ConcurrencyPolicyMRSW.java:132)
> at com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.policyError
> (ConcurrencyPolicyMRSW.java:127)
> at com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.checkConcurrency
> (ConcurrencyPolicyMRSW.java:64)
> at com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.startRead
> (ConcurrencyPolicyMRSW.java:31)
> at com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.startRead
> (NodeTupleTableConcrete.java:60)
> at com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.findAsNodeIds
> (NodeTupleTableConcrete.java:132)
> at com.hp.hpl.jena.tdb.store.TripleTable.find(TripleTable.java:71)
> at com.hp.hpl.jena.tdb.store.GraphTDBBase.graphBaseFindWorker
> (GraphTDBBase.java:115)
> at com.hp.hpl.jena.tdb.store.GraphTriplesTDB.graphBaseFind
> (GraphTriplesTDB.java:61)
> at com.hp.hpl.jena.sparql.graph.GraphBase2.find(GraphBase2.java:232)
> at com.hp.hpl.jena.sparql.graph.GraphBase2.graphBaseFind
> (GraphBase2.java:253)
> at com.hp.hpl.jena.sparql.graph.GraphBase2.find(GraphBase2.java:249)
> at com.hp.hpl.jena.rdf.model.impl.ModelCom.listStatements
> (ModelCom.java:378)
> at com.hp.hpl.jena.rdf.model.impl.ModelCom.listStatements
> (ModelCom.java:383)
> at com.hp.hpl.jena.rdf.model.impl.ModelCom.getProperty
> (ModelCom.java:1003)
> at com.ibm.lld.store.TDBMetadataStore.storeCurrentETag
> (TDBMetadataStore.java:75)
>
> I believe I'm correctly acquiring a WRITE lock. This is the failing
code in
> my class TDBMetadataStore:
>
> public void storeCurrentETag(String resourceURI, String etag)
> {
> fResourceDataset.getLock().enterCriticalSection(Lock.WRITE);
> try {
> Model model = fResourceDataset.getDefaultModel();
> Resource resource = model.getResource(resourceURI);
> LINE 75 --> Statement etagStmt = model.getProperty(resource, IndexMeta.
> ETag);
>
> Shouldn't it be impossible to get to line 75, while there's an
outstanding
> Reader?
>
> I'm using the latest TDB release (0.8.10). Any ideas what could be
causing
> this?
>
> Thanks,
> Frank.
