TLock revival

[Oliver Zeigermann <oz...@c1-fse.de>]

Folks!

I took up the TLock idea initially present by Peter Nevermann and 
Michael Hartmeier.

My TLocks can be set on any resource and are
- transient: they will be automatically removed at the end of a 
transatction which currently ends when the request ends
- exclusive: at most one transaction can hold such a lock on the same 
resource

TLocks are currently used only on creation and removal of resources. In 
this case the parent of such a resource will be locked exclusively. The 
reason for this is to avoid deadlocks especially when auto-versioning is 
turned on. Let me show how things were before this:


BEFORE TLOCKS
-------------

(I) Pessimistic locking

Tx1				Tx2
1 Read history			XXX
2 XXX				Read history
3 XXX				XXX
4 Try Write histroy (wait)	XXX
5 Wait				Try Write histroy (wait)
6 Wait				Wait
7 Wait 				DEADLOCK -> ROLLBACK
8 Commit

(II) Optimistic locking

Tx1				Tx2
1 Read history			XXX
2 XXX				Read history
3 XXX				XXX
4 Write histroy 		XXX
5 XXX				Write histroy
6 XXX				XXX
7 Try commit ->			XXX
   Concurrent Modification ->
   ROLLBACK
8 				Commit


AFTER TLOCKS
------------

Tx1				Tx2
1 Lock history			XXX
2 XXX				Try Lock history (wait)
3 Read history			Wait
4 Write histroy			Wait
5 Commit (releases all TLocks)	Wait
6				Histoty Locked
7 				Read history
8 				Write histroy
9 				Commit


CONFIGURATION
-------------

There is nothing special to do as TLocks are now part of the 
ExtendedStore. TLocks have timeouts as well which is the maximum amount 
in seconds a transaction will wait for a TLock until it rolls back and 
reports a conflict. The default is 20 seconds, but you can change it in 
Domain.xml using parameter tlock-timeout. The configuration might look like:

      <store name="TxFileStore">
        <parameter name="tlock-timeout">20</parameter>
         ....
      </store>


CONCLUSION
----------

Using TLocks and Sequences I could concurrently upload from seven 
clients each having 100 resources without a single conflict. Of course, 
concurrency is reduced as at most one writing (pure reading is not 
affected) transaction can have access to the history folder at a time. 
This is still much better than to lock the whole PUT method or apply 
weired hacks as done before.

That's it I guess...

Cheers,
Oliver

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