OK, that's pretty clear (and not supposed to be), but at least I can search for something I neglected to wrap in begin()end(). Thanks.
On Wed, Mar 28, 2012 at 9:30 AM, Andy Seaborne <a...@apache.org> wrote: > On 28/03/12 13:59, Bernie Greenberg wrote: > >> 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. >> > > "serialized" in isolation level terms means you do not need > to do anything in different threads. > > Separate transactions see safe, independent views of the data. No > locking by app needed. > > Nothing to do with "serialized" in Java. > > You do have to ensure they are different transactions, that's all. > > The stacktrace you showed suggests to me that there are two treads > accessing the same dataset but there are not the matching .begin() calls. > > Andy > > > >> On Wed, Mar 28, 2012 at 8:40 AM, Andy Seaborne<a...@apache.org> 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 >>> >>> >> >
