Well, as they say in Java, that's a new plate of beans; OK, so I have to ensure by my own devices that transactions in different threads are serialized. According to the previous email sent me, overlap is an error situation, as your "not in the new Txn system" suggests.
On Wed, Mar 28, 2012 at 8:40 AM, Andy Seaborne <[email protected]> wrote: > (catching up on specific points first) > > > On 27/03/12 17:38, 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? >> > > Not in the new transaction system - a READ transaction and a WRITE > transaction can overlap. Any READ starting before WRITE commit, will not > see the WRITE changes even after the WRITE commit. Any READ starting after > the commit will see the changes. In ACID speak: transactions in TDB are > fully "Serializable". > > Andy >
