On 09.05.14 09:25, Roland Kuhn wrote:
9 maj 2014 kl. 09:08 skrev Martin Krasser <krass...@googlemail.com
<mailto:krass...@googlemail.com>>:
On 09.05.14 08:41, Roland Kuhn wrote:
Hi Martin,
9 maj 2014 kl. 08:05 skrev Martin Krasser <krass...@googlemail.com
<mailto:krass...@googlemail.com>>:
Hi Roland,
thanks for starting a discussion on this. Here are some initial
thoughts on your proposal:
"... very same throughput optimization by applying the state
changes before persisting them ..."
I think we agree that whatever changes are going to be made in the
future, we must keep the throughput optimizations (by batching
writes/updates). As you said, with an EP, this can only be achieved
by applying events to current state *before* persisting them.
Furthermore, to enable batching, an EP must therefore be able to
process new commands while (previous) events are about to be
persisted. This however has a very important consequence for
commands that read current state. If we allow events to be applied
to current state *before* persisting them, we allow clients to read
state from that EP that may not be re-readable after a crash. For
example:
- EP receives update command, derives event and applies it
immediately to current state
- EP (asynchronously) persists event
- EP receives a read command (while event persistence is in progress)
- EP (successfully) returns read response to requestor
- EP JVM crashes before event was successfully persisted
- EP state cannot be reconstructed i.e. previous read cannot be
repeated.
This is only true if the recovery is incomplete: the update command
will not have been acknowledged at this point, so if someone cared
about it they will send it again during recovery and the EP will
eventually end up in a state where the read will return the same
value again. If this type of consistency is not good enough, then
you can always defer reads within the write model until after
persistence is completed, meaning that the read is only performed
once a corresponding read “event” has gone through the journal. We
could allow events that are only looped through to make this work,
just like non-Persistent commands are looped today (and for the same
reason).
Delaying reads is only an option when reads are made via messages to
a (E)P. If my processor manages state via an STM ref where only the
processor updates the STM ref but reads go directly to the STM ref,
then you cannot delay reads.
In this scenario you would delay updating the STM ref until after the
persistence loop, which is exactly the same as for a current
command-sourced Processor: the read gets delayed until after the
writes are processed, in the same way the STM ref update gets delayed
by the write having to go through the journal. Effects, consistency
and latency are the same in both implementations.
That's true. So, to achieve
- repeatable reads
- low read latency and
- high write throughput
reads can go to the STM refs directly and EP must update the STM ref
only after having persisted the events. If one *additionally* wants to
achieve
- read-your-own-write consistency (assuming a client issues an update
command, immediately followed by a read command)
one would need a way to loop read commands through the journal as well
before serving them (which probably requires an addition to the API
then). Alternatively, a client only issues a read after having received
a write-ack (at the cost of an additional roundtrip). Anyway, I think
you convinced me, as usual :) Great proposal, Dr Kuhn!
Cheers,
Martin
--
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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
