Since I have an opportunity to say more (and feel I need to clarify more given what you have said), let me take it. One thread is a reader, another thread a writer. The write thread has opened a write transaction, and, hopefully, the read thread tries to open a read transaction and gets blocked (by Jena) until the write transaction finishes by calling end(). If I am describing my software accurately, and the transactions do synchronize, unless I have a bug where I do read-like operations without having bracketed them in a begin(read);end(), I do not see how it should be possible that (your analysis) "a reader is inside the same transaction as a writer" might be the case; I'm not even sure what you mean -- do you mean a thread that has failed to bracket with begin(read);end(); properly? Are global read operations (construct empty model, etc) not addressed to a specific dataset not allowed during by other threads during write transactions?
Thank you for your time; if all else fails, I will try critsec mutual exclusion, but I'd like to understand the model if, in fact, I don't. On Tue, Mar 27, 2012 at 4:14 PM, Andy Seaborne <[email protected]> wrote: > 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.**ConcurrentModificationExceptio**n: 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_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_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<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_**<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<http://incubator.apache.org/jena/documentation/tdb/tdb_transactions.html#multi-threaded_use> >>>> >>>>> >>>>> >>>>>> How is your coworker's testign using the transaction mechanism? >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >
