These are chat archives for RBMHTechnology/eventuate

Dec 2016
Benjamin Nash
Dec 02 2016 00:02
@krasserm Thanks for the clarification. That helps a lot.
Volker Stampa
Dec 02 2016 12:49
@jrgonzalezg As far as I understand your application receives commands that do not contain an id of the addressed entity, but just some selection criterion that is used to find the correct entity. Compared to the order management example the manager that dispatches the commands to the corresponding aggregates (the OrderActors) has to find the right instance not by its aggregate id but by some arbitrary criterion. In general I would propose to query a view in that case to find out about the id and dispatch afterwards to the corresponding actor. To make sure that a client sees its own writes (as the view is only eventually consistent) you could use conditional requests. This assumes that your entities/aggregates actually define the transactional boundary, so multiple aggregates can handle multiple commands in parallel while each aggregate handles commands sequentially. Depending on your requirements your proposal to keep all entities in one actor could also be valid. In that case access to all entities would be sequential, so the approach probably does not scale that well.
Regarding the id generation I guess using a global unique id generator (like java's UUID, twitter's snowflake, etc.) would be the simplest solution. If you prefer to use a counter as you already mentioned it must be amended by some type-id (for the different aggregate types), but also by a location id if you go distributed.
Juan Ramón González
Dec 02 2016 17:15

Thanks @volkerstampa!, i may need to use the conditional requests and i have also not thought about the locations affecting the global ID collision (since i was starting with just one location), but i may need that too... Also, i have some queries that are referred to just one place (which could be handled in the same way as orders on the order management example) but i also have many queries for finding places in a radius around a location, so it was clear to me that i needed a view with access to all the places for being able to do that second kind of queries.

What i am not sure if it is a good idea to make that big view also handle the search of the aggregates for the purpose of ID retrievals since it may be better to have a different view, or to use a simplified write model on the actor that receives the commands coming from the parsed data.

Also, if actors process messages sequentially, how would you handle concurrent queries? My concern is that if i create many copies of that view actor that has a big in-memory read model each, the resource usage could be quite higher than on the current backend. Is it possible / sensible to have child actors that share the state of that view actors? Or.. does it make sense to create threads on a view actor to handle more queries without necessarily creating more copies of the actor?

Marco Ehrentreich
Dec 02 2016 20:25
@jrgonzalezg I'm not an expert on actors but I'm very sure that actors are a much cheapter than threads
Marco Ehrentreich
Dec 02 2016 20:45
btw. maybe it would help to use a view to populate some kind of storage which makes it easier to find the matching entities again when you don't have an ID
something like Elasticsearch or similar?