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 >
