Looking at the stack more closely, I see that the problem is because TDB
(line 30 of com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW, i.e., 4 down
from top-of-stack) is acquiring a read lock after I acquired my WRITE lock:
public void startRead()
{
readCounter.getAndIncrement() ; <--- LINE 30
checkConcurrency() ;
}
Is that expected? Why is it incrementing the read counter while I already
have a WRITE lock?
Statement etagStmt = model.getProperty(resource, IndexMeta.ETag);
I've been using a pattern like this in many places without noticing any
problems before:
public void storeCurrentETag(String resourceURI, String etag)
{
fResourceDataset.getLock().enterCriticalSection(Lock.WRITE);
try {
Model model = fResourceDataset.getDefaultModel();
Resource resource = model.getResource(resourceURI);
Statement etagStmt = model.getProperty(resource, IndexMeta.ETag
);
if (etagStmt != null)
etagStmt.changeObject(etag);
else
model.add(resource, IndexMeta.ETag, etag);
} finally { fResourceDataset.getLock().leaveCriticalSection(); }
}
Thanks,
Frank.
Frank Budinsky/Toronto/IBM@IBMCA wrote on 05/17/2011 09:53:15 AM:
> [image removed]
>
> Concurrency problem
>
> Frank Budinsky
>
> to:
>
> jena-users
>
> 05/17/2011 09:54 AM
>
> Please respond to jena-users
>
>
>
> Hi guys,
>
> 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.
