We are using messaging in a project of ours to implement pessimistic concurrency. This means that if messaging goes down (channel goes down), concurrency goes down.
I'm thinking more of combining the optimistic and pessimistic concurrency. Then if pessimistic concurrency goes down, there's still a backup optimistic concurrency...
thx, Lieven Cardoen
As usual, I think the answer depends on the nature of the business application that you are building. What are the SLAs for your application? How mission critical is it?
If your messaging infrastructure faults, does the application continue to function aside from the lock service? If so, then you probably have an obligation to make sure your concurrency control mechanism isn't the single point of failure.
Furthermore, the topic of achieving a truly distributed, fault-tolerant pessimistic locking mechanism requires one to address the problem of consensus. Most pessimistic locking algorithms rely on there being a single, serialized authority that can respond to requests for locks (i.e. there's a "lock" table or perhaps there's a singleton lock server).
Such a design has single point of failure written all over it. To answer your first question--Yes, I've seen business applications use messaging to provide pessimistic locking. However, fully solving the fault tolerance problem seems like overkill for most business applications I've encountered.
Optimistic concurrency control does not have this problem by its nature which is why it's generally preferred in distributed, fault-tolerant applications. However, I realize that business requirements frequently win out over ease-of-implementation.
If the topic interests you, Google has published an article on their Chubby Lock Service which leverages the Paxos consensus protocol.