b.Pessimistic Offline Lock Pattern

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.

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.

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.