Re: Clustering a DDD/CQRS/ES app

Hmm how do you handle commit protocol?

Ex I talk to server 1 and say write aggregate a event 12

You at same time are talking to server 3 and say same thing one of us will
get to server 2 (makes quorum) first.

On Monday, April 8, 2013, Rickard Öberg wrote:

> Ok I have updated the code to do clustering on EventStore level instead.
> Added support for initial population from other instances in cluster. Works
> great!
>
> When events are distributed each store checks if version of aggregate in
> event matches local version+1. If no, then concurrent update has occurred
> and event is discarded. On instance that caused that event the inmemory
> copy of aggregate in repo is cleared and REST API reports 409, with option
> to redo command instead. It has support for etags as well, so long running
> optimistic concurrency works too, if desired.
>
> For Javaites, see code on Github for details. Feedback is most welcome.
>
> /Rickard
>
> Sent from my iPad
>
> On 6 apr 2013, at 17:29, Greg Young <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>>
> wrote:
>
>
>
>
> On Sat, Apr 6, 2013 at 12:26 PM, Rickard Öberg <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>
> > wrote:
>
>> Thanks for reply on this fascinating topic!
>>
>>
>> On 4/6/13 17:19 , Greg Young wrote:
>>
>>> What happens when your cluster is running 3 versions of software and the
>>> 3 versions all calc slightly differently?
>>>
>>
>> Yes that's definitely an issue.
>>
>>
>>  What if you want to do some for of synchronous integration during the
>>> processing of a command?
>>>
>>
>> So basically process the command on the local process and when event(s)
>> are generated distribute that (in my case with HazelCast). What about
>> locking, i.e. if someone else sends commands to same aggregate on another
>> server at the same time? Local locking is trivial ("synchronized" will do),
>> but across cluster?
>
>
> Thats the beauty of the model discussed below. What ends up happening in
> the event store is that there are paxos elections. Distributed locks become
> forwarding and local locks.
>
>>
>>
>>  For dealing with a new server it would just have a durable subscription
>>> (more on that later). When it came in it would start at 0 and move
>>> forward. It would be in a state of replicating until it caught up. A
>>> very easy way to do this for many people is to just run EventStore as
>>> embedded in their process (or hosting it as a separate process on each
>>> node). This is exactly what it will do.
>>>
>>
>> Yes, that makes sense.
>>
>>
>>  Its also not needed to pin to a server though using keepalives will give
>>> you this 99% of the time. What we do is a quorum of servers have
>>> responded to your write before we say that the write has completed. If
>>> you want 100% assured write/read semantics in all failure conditions you
>>> can just read from a quorum of servers.
>>>
>>
>> Does this assume that there is no load balancer in front? I.e. you have
>> round robin DNS instead?
>
>
> in this case yes.
>
>
>>
>>
>> /Rickard
>>
>>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
>

-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.