TLocks, External Transaction and Deadlocks

[Oliver Zeigermann <oz...@apache.org>]

Warning: This post will be pretty long, complicated and boring for most 
people!

Motivation
----------

We had an issue with some other software the other day where we had some 
sort of distributed deadlock. I.e. neither the database nor the Java 
application by itself had an deadlock, but the database had some locks 
and the application as well where each was waiting for the other.

TLocks
------

Next to the sequence concept TLocks were introduced to avoid conflicts 
when more than one Client uploads data when autoversioning is turned on. 
  Sequences allowed for unique history numbers even when the cache not 
completely isolated transactions. The other problem was deadlocks were 
one transaction gets rolled back resulting in a conflict response as 
well. This does happened regularly when the history folder was accessed 
either to increment the history number or to add new children to it 
which happened with each versioning request. Now when a new resource is 
to be created its parent is locked exclusively for the duration of a 
transaction avoiding these problems. Those locks are called TLocks.

Before those TLocks all locking was done solely in the database. Thus 
there was no risk of distributed deadlocks. Even with TLocks in Slide 
this risk does not exist as every request goes through the same code in 
StructureImpl and acquires locks in the same order. This means if we 
have two transactions spawned by requests both try to acquire the TLock 
first. Thus there is no risk of a distributed deadlocks even with TLocks.

External Transactions
---------------------

Right now transaction control in Slide is not accessible and 
influenceable from the outside. This will change when external 
transactions are introduced. Using them you can combine random requests 
in one transaction. Because this is so there might be combinations (even 
though I can not think of one right now) of requests in two transactions 
where one has a lock in the database and one a TLock in Slide and each 
waits for each other. This would be a distributed deadlock like the one 
described above.

The solution to this is to disable TLocks when using external 
transactions. This is not that bad as TLocks are not necessary for 
correctness, but only to avoid conflicts.

Caching
-------

Currently, caching does no locking at all. This is good as there can be 
no deadlocks with caching, but bad as the cache has a rather weak 
isolation level. Avoiding dealocks is mandatory, so there can be no 
locks for the cache. In order to achieve better isolation I will 
investigate mechanisms that work without locks and never roll back. I 
will keep you informed.

Thanks for the attention and cheers,

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org