>>> One issue is that a thread does not always know what locks it needs
>>> before the fact.
>> Yes, this is the killer. Often it's not possible to know what locks you
>> want until you read some data (which you have to lock first). And if you
>> release the locks, somebody else could come and change the data...
> 
> Isn't that the point? I've never worked with a low-level locking setup, but
> I implemented a high-level one in the CMS I'm currently working on. If
> somebody accesses a specific item, it is locked with a timeout. If he
> doesn't commit changes within 15 minutes (or whatever is set), he "loses"
> the lock, and somebody else can edit.
> 
> I.e. releasing a lock = it's ok for somebody else to change the data. You
> have the lock = everybody else is blocked from changing the data?

My point is, you can't just go "I've got lock 7 and lock 13, and now I 
need lock 2, so I'll just release lock 7 and lock 13, then take lock 2 
and take back lock 7 and lock 13". In between releasing the locks and 
taking them back, something could change. You need a better plan than that.

Post a reply to this message