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
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 <b...@basistech.com> wrote:
> Thanks; I will (continue) looking at these.....
>
>
> On Tue, Mar 27, 2012 at 1:42 PM, Paolo Castagna <
> castagna.li...@googlemail.com> 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 <a...@apache.org> 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
>> >>
>> >
>>
>
>
