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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to