On 27/03/12 20:20, Bernie Greenberg wrote:
Below is part of a stack trace (which says what I already said, that a
reader tried to begin a read transaction while a single legitimate writer
was a-writing). The diagnostic seems to indicate that this is not a state
of affairs it supports.
I have looked at the two URL's you sent, and notice immediately that while
my code, pursuant to your documentation, calls begin/end on datasets, but
the code in the new files calls begin on a StoreConnection, obtaining a
DataSetGraphTxn on which it later calls commit() and end(). What's the
story here?
Thanks.
Bernie
Bernie, I'll look in more detail tomorrow but that exception is the
internal check that triggers with a writer AND a reader are inside the
same transaction. Best not
More soon,
Andy
2011-09-12 12:36:04,049
com.hp.hpl.jena.sparql.engine.QueryExecutionBase - Exception in
insertPrefixes: Reader = 1, Writer = 1
java.util.ConcurrentModificationException: Reader = 1, Writer = 1
at
com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.policyError(ConcurrencyPolicyMRSW.java:127)
at
com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.policyError(ConcurrencyPolicyMRSW.java:122)
at
com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.checkConcurrency(ConcurrencyPolicyMRSW.java:60)
at
com.hp.hpl.jena.tdb.sys.ConcurrencyPolicyMRSW.startRead(ConcurrencyPolicyMRSW.java:32)
at
com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.startRead(NodeTupleTableConcrete.java:60)
at
com.hp.hpl.jena.tdb.nodetable.NodeTupleTableConcrete.find(NodeTupleTableConcrete.java:115)
at
com.hp.hpl.jena.tdb.store.DatasetPrefixesTDB.readPrefixMap(DatasetPrefixesTDB.java:153)
at
com.hp.hpl.jena.sparql.graph.GraphPrefixesProjection.getNsPrefixMap(GraphPrefixesProjection.java:51)
at
com.hp.hpl.jena.rdf.model.impl.ModelCom.getNsPrefixMap(ModelCom.java:817)
at
com.hp.hpl.jena.shared.impl.PrefixMappingImpl.setNsPrefixes(PrefixMappingImpl.java:100)
at
com.hp.hpl.jena.rdf.model.impl.ModelCom.setNsPrefixes(ModelCom.java:794)
at
com.hp.hpl.jena.sparql.engine.QueryExecutionBase.insertPrefixesInto(QueryExecutionBase.java:278)
On Tue, Mar 27, 2012 at 2:38 PM, Bernie Greenberg<[email protected]> wrote:
Thanks; I will (continue) looking at these.....
On Tue, Mar 27, 2012 at 1:42 PM, Paolo Castagna<
[email protected]> wrote:
Hi Bernie,
perhaps you can have a look at two or three small test programs in the TDB
test suite which run read/write transactions concurrently.
If you want, you could try to run them and see if they give you a problem
or check if there is anything you do which is significantly different and
try to replicate your usage scenario there:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating/src/test/java/com/hp/hpl/jena/tdb/transaction/T_TransSystemMultiDatasets.java
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating/src/test/java/com/hp/hpl/jena/tdb/transaction/T_TransSystem.java
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating/src/test/java/com/hp/hpl/jena/tdb/transaction/T_TxnDeadlockTest.java
Paolo
Bernie Greenberg wrote:
I don't know (businesswise) if I can post my stack trace or details of
my
code, but, first of all, my coworker was testing the code I had
modified;
he didn't write any new code, he just operated its UI correctly.
One thread was in "begin(WRITE); make model; add assertions; commit;
end()" on the dataset, and the other attempted to" begin(READ);
construct
map; end()," but instead of waiting in begin(READ), caused the thread
with
the write-lock to crash. The cited URL addresses a type of abuse of
which
I wouldn't dream, if I understand it correctly (one thread exploiting
another's ownership of the database). I would expect that, with no
further
code, a thread doing a begin(READ) should wait for a thread that
successfully executed begin(WRITE) to exit from end() before the
begin(READ) returns to its caller; is this not so?
If you truly need more stack trace, I'll see what I can do.
Bernie
On Mon, Mar 26, 2012 at 4:40 PM, Andy Seaborne<[email protected]> wrote:
On 26/03/12 16:13, Bernie Greenberg wrote:
The new transaction primitives worked superlatively for me, but not
for my
coworker testing my code. As soon as he issued a query while updates
were
going on, the latter crashed. mid-transaction.
Does dataset.begin/dataset.end provide, in addition to transaction
safety,
thread synchronization/locking as well (as I imagine(d)), or must I
wrap
Jena critical sections around each such pair if that is what I
expect? (In
either case, the doc for begin/end should say).
Thanks,
Bernie
Bernie,
Do you have a test case or details of the crash?
Within a transaction all access must be multi-reader or single-writer.
The
normal pattern is one thread, one transaction.
http://incubator.apache.org/**jena/documentation/tdb/tdb_**
transactions.html#multi-**threaded_use<
http://incubator.apache.org/jena/documentation/tdb/tdb_transactions.html#multi-threaded_use
How is your coworker's testign using the transaction mechanism?
Andy
