(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
