On 06.05.14 08:18, Ashley Aitken wrote:
Hi Martin,
Thank you for your response to my questions.
On Tuesday, 6 May 2014 13:13:46 UTC+8, Martin Krasser wrote:
Finally, I believe I would like to track all the events that get
added to the entire journal (treating it like a combined log).
Is that possible? Is it one big log-like thing or are there
really separate journals for each Processor?
Each processor has its own logical journal, although journal
plugins maintain them in a single physical backend store
(replicated or not). This is not a requirement but all plugins
follow this pattern so far. So, from a physical viewpoint there's
a single big message store but this doesn't mean that there is a
global ordering of messages. An ordering of messages is only
defined within a processor (i.e. logical journal). Messages from
different processors are seen as unrelated by akka-persistence.
This is an interesting twist (IMHO), with regards to Eventsourcing
with Akka Persistence. I was under the (perhaps naive) impression
that in ES there would logically be some sort of event log that kept
all events and that components could subscribe to such events.
This event log is per processor (optionally with n views as
subscribers). The reason that there's no global log (with a global
ordering of messages) is write scalability: processors can reside on
different nodes and having a global counter for all would limit
scalability. An interesting alternative could be information about
causal ordering of messages between processors (not implemented (yet))
and this could be implemented in a scalable way.
AP seems to be taking a different tack with per processor logical
journals that are polled (in some sense, please correct me if I am wrong).
Polling, as done by views, is an implementation detail. Later version of
akka-persistence may provide a push-based approach as well. Processors
only write to the journal during normal operation (and read from it only
during recovery).
I guess the proposed change / ticket will at least allow a View to
follow all events.
Similarly, what about a View that tracked changes to all Orders
and all Receipts?
My understanding is that the Views will be used to update the
read model (e.g. some denormalised store, like MongoDB optimised
for client querying).
Yes, views are there to maintain read models. They may also keep
state in memory (and take snapshots) since it can be recovered by
replaying messages (optionally starting from a snapshot).
Good so I am on the write track. I am confused a little about the
Views keeping stage in memory and with snapshots. What state would
this be? Surely the read model itself is maintaining most of the
state, e.g. in a database. Could the Views themselves sometimes be
the read model that were queried by the client? Is that meant to be
the primary approach or not?
Yes, this is meant to be the primary approach.
Views that track updates from many processors make absolutely
sense and have already been requested several times (see ticket).
Ok, this is good, I just thought perhaps I was not understanding the
design of Akka Persistence and the way it should be used for CQRS/ES,
for example. I have read the discussions and thanks for pointing out
the ticket. I won't ask when we can hope for a solution but I will
ask (not necessarily you but anyone reading) what are people doing
until then?
There are several options, some are
- Let the backend store (Cassandra, MongoDB or whatever) update custom
views (e.g. database tables) whenever a new message is added to the
journal (using triggers).
- Let processors update a database directly to create a view (via
channels to avoid duplicates during replay).
- ...
Thanks again for answering my newbie questions.
I am really impressed with the elegance and simplicity of Akka
Persistence and it's CQRS/ES components.
Cheers,
Ashley.
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
