Hi,
Do you have any thoughts on implementing a LockManager using a distributed system, such as ZooKeeper ?
Hi Nicolas,
my thoughts: don’t. That would break rule #1 of distributed computing.
But seriously, I’d recommend using a mechanism like consistent hashing to distribute activity and prevent locking altogether. Distributed locking is complex, prone to failure and expensive, performance wise.
Is there a specific area in which you were considering using a distributed lockmanager?
Cheers,
Allard
I’m mostly concerned by things that cannot be “undone”, things for which no reasonable compensating actions exist (financial transactions, file system operations, external API calls, etc.).
Since I use optimistic locking, the approach I use right now is to execute these actions in event handlers, once the originating transaction is committed.
I was looking at other alternatives, such as distributed pessimistic locking using a distributed lock manager like ZooKeeper.
Forgive me for my ignorance, but isn’t distributing commands (whatever the mechanism) just as evil, considering the underlying mechanism needed to handle failures and elasticity of demand ?
H Nicolas,
where do you use optimistic locking? In the repository of the command handling component?
The approach to use event handlers for these kind of things is normally my default way to do it. Do you want to perform this logic in another place?
I’m not really sure I understand what you’re trying to achieve.
The Distributed Command Bus uses consistent hashing, not locking, to distribute commands between nodes. It takes less chatter-overhead between the nodes to get things done. If there is a failure, each node knows exactly what other node is the fallback for executing the command. It’s evil in that it breaks rule #1 of distributed systems, but that’s a rule you need to break if you need failover/scalability.
Cheers,
Allard
Hi Allard,
Thank you for your answer. I use optimistic locking on the repository.
Doing the irrevocable actions in event handlers is also my default option, although I would like very much to be able to do this in the domain itself, as it seems less contrived. Even if pessimistic locking is used (whatever the mechanism), or that it is guaranteed that commands for an aggregate are never executed simultaneously (using jgroups), there is still a distinct but rather small chance that appending the event stream will fail when the uow is committed. The only way to be “right” 100% is to execute the actions in a posteriori event handlers.
I came to the same conclusion myself but wanted a second opinion, just to make sure I was not misguided.
Thank you