Re: Lock Management Services

Tim,

I tried to mail this to you, but got an error:

Unless the Lock Management Service has changed since I had a go with it 18 months ago, I think you have read more into it than exists.

User-defined locks are simply 'magic cookies' with no inherent meaning. They can only (safely) mean something if _every_ program in your application knows what they are supposed to mean.

If you want UL 123123123 to mean 'Table M, row X' you have to write an algorithm that translates the table and row identity into a unique, legal, lock number and back again.

Then, for your example, you would have to

	generate the lock number for the first row,
	take out the user-defined lock
        generate the lock number for the second row
	take out the user-defined lock
        update the second row (which would, of course, lock it 'normally')
        release the lock on the first row,
	commit at leisure (implicitly releasing the second UL).

However, every other program that might want to update/delete and otherwise muck about with the first row _also_ has to do so by first trying to acquire its associated user-defined lock.

There are 3 main problems:

1. Making sure all the programs behave is likely to be impossible
2. Writing your own algorithm for row/lock cross-reference is likely to be rather hard. (And you can't use the supplied mechanism for turning a token into a lock id as it issues a commit).
3. The notes advise you to be sparing with creating user-defined locks for performance reasons.

-- 
Jonathan Lewis