- Motivation
- Prevents conflicts between concurrent business transactions by allowing only one business transaction at a time to access data.
- Summary
- Pessimistic Offline Lock prevents conflicts by avoiding them altogether. It forces a business transaction to acquire a lock on a piece of data before it starts to use it, so that, most of the time, once you begin a business transaction you can be pretty sure you'll complete it without being bounced by concurrency control.
- If you have to use Pessimistic Offline Lock, you should also consider a long transaction. Long transactions are never a good thing, but in some situations they may be no more damaging than Pessimistic Offline Lock and much easier to program. Do some load testing before you choose.
- Don't use these techniques if your business transactions fit within a single system transaction.
- When to Use
- Pessimistic Offline Lock is appropriate when the chance of conflict between concurrent sessions is high. A user should never have to throw away work.
- Pessimistic Offline Lock is very complementary to Optimistic Offline Lock (416) and only use Pessimistic Offline Lock where it's truly required.
- Implementation
- You implement Pessimistic Offline Lock in three phases: determining what type of locks you need, building a lock manager, and defining procedures for a business transaction to use locks.
- Additionally, if you're using Pessimistic Offline Lock as a complement to Optimistic Offline Lock you need to determine which record types to lock.
- References
- http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html
|
|