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<[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
