Friday, May 12, 2006

ACID Fundamentals - Locks

I'm wading around in the guts of transaction locking code and it is nothing short of a nightmare! I have a number of generic classes which do all the hard work these are then specialised by final classes for each lock type which deal with the specifics. These "specifics" amount to handling state transitions and determining compatable lock types from different transactions and even the state class is defined within the generic implementation - very clean and somewhat tidy.

Right now I cannot decide whether the escalation behaviour needs a way of being plugged into this generic implementation and I still don't know where to put contextual information such as "whether to hold a read lock until the end of a transaction" as it can't stay in the DatabasePage object...

While I investigate escalation options, I have split the Page lock into seperate sub-types;


  • Database Locks

  • Root Page Locks

  • Object Locks

  • Distribution Page Locks

  • Extent Locks

  • Schema Locks

  • Page Locks



Each of these locks has slightly differing state logic and this is the cleanest way of dealing with that.

Added a collection object to the transaction context which allows transaction context to track the objects which have outstanding locks during the lifespan of a transaction. This is very important when using ReadCommitted (with hold lock) isolation and above as these locks will be released after the commit/rollback has happened - hence the best place for that is the transaction context - not the lock manager!

Weekend should involve more major work on this project - it's Friday already and I should be sleeping!

No comments: