Darren New schrieb:
> clipka wrote:
>> So if performance is an issue, and it is not known beforehand what 
>> locks may be required to complete the operation, this locking concept 
>> is usually not an option.
> 
> I don't think you have a choice, if you want ACID-style guarantees that 
> your changes are committed and valid. :-)  Everything else breaks down 
> to doing locks and retrying for a deadlock.

If noticing during an operation that you'll need an additional "lower" 
lock is a frequent situation you'll encounter, then risking deadlock may 
be the more performant option. Especially if all you really need are a 
few individual pages from a database, for instance, so that the risk of 
deadlock may actually be quite low. You'd be in for a retry anyway, 
whether you need to rollback to ackquire additional locks or to break up 
a deadlock.

Of course, if you absolutely positively know which locks you'll need, 
ordered locking seems to be the way to go.

If you're not sure, then of course you can acquire just any lock you 
/may/ possibly need, but that'll degrade performance as well.

Post a reply to this message