On 17/05/11 16:21, Frank Budinsky wrote:
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
Unrelated operation. This tracking the low level operations.
readCounter is an AtomicLong.
checkConcurrency() ;
}
Is that expected? Why is it incrementing the read counter while I already
have a WRITE lock?
It's expected.
Because the code is doing
listStatements
==>
graph-level find
and every operation declares what sort of operation it is.
find is a read of the NodeTupleTable for the default graph.
At the end of the find, it will do a finishRead --
@Override
public Iterator<Tuple<NodeId>> findAsNodeIds(Node... nodes)
{
try {
startRead() ;
....
return find(n) ; // **public call
} finally { finishRead() ; }
(and the find iterator has a wrapper to check access.)
ConcurrencyPolicyMRSW uses these start/finish calls to track the state
of the object it's the policy for.
ConcurrencyPolicyMRSW thinks there is a read operation (this code) and a
writer (somewhere else).
Locking via enterCriticalSection is separate. ConcurrencyPolicyMRSW is
the always present checking code.
Andy
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.
