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:
Post a Comment