On 28.07.14 23:40, Konrad Malawski wrote:
Rephrasing my ordering question actually (it started out as something
else and ended up as weirdly worded):
I was thinking if the guarantees should be "time in system" or happens
before as known by sequence numbers in concreten ids's (A-1 before
A-2, but B-1 before B-2, but I don't care about A and B relation).
- a total order per persistenceId based on sequence numbers (= partial
ordering in the "all events" stream) is a must have IMO.
- ordering based on timestamps should be an application level concern (=
timestamps in application-defined events and (re-)ordering done by
application)
- mid/long-term goal: causal ordering (allows moving from eventual
consistency to causal consistency). See also Don't Settle For Eventual
Consistency <http://queue.acm.org/detail.cfm?id=2610533>.
Curious about your real world use cases in other words.
Less caring about ordering makes way for faster replays of course - so
that's what I'm after here (perhaps thinking to far ahead though).
-- k
W dniu poniedziałek, 28 lipca 2014 22:49:00 UTC+2 użytkownik Konrad
Malawski napisał:
Hi everyone,
thanks for your feedback and ideas.
So the stream / view on multiple persistentIds (or “tags” - would
solve Greg’s example case) is coming, we just have not yet have
had the time to work on it.
One thing that ties in into them is reactive streams. We would
like to expose these event streams as akka streams.
Esp. since they provide they provide things like merge / filter /
tee which I believe would help a lot in these kinds of event
streams :-)
From the streams point of view abstracting if it’s polling or
DB-side initiated events the APIs won’t have to change.
I do agree / like Martin’s suggestion that in “normal dbs” (no
events when someone does an insert) we should be able to implement
this with some housekeeping done by the plugins.
One question about EventStore, in the case of reading from
multiple replication groups is the ordering based simply on
write-timestramp not-descending order?
The timestamp is obviously skewed a bit (multiple servers/clocks
do writes) but in the apps you work with would this be ok as
source of ordering in case of the “all events” stream?
PS: Most of the team is on holiday this week, it’s reasonable to
expect they’ll chime in some time next week.
--
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io
--
>>>>>>>>>> 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
<mailto:akka-user+unsubscr...@googlegroups.com>.
To post to this group, send email to akka-user@googlegroups.com
<mailto: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.
--
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 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.
