9 maj 2014 kl. 14:57 skrev Chanan Braunstein <[email protected]>:

> Since you asked for feedback:
> 
> We are using EventsourcedProcessor and have no plans to use Processor. We saw 
> the benchmarks and read the docs that Processor is faster, but choose to 
> model our system using traditional DDD. We understood the trade-off we were 
> making. The proposal to add something like async=true is perfect for us. We 
> can then decide which aggregates should have full consistency (even down to 
> the event level although, I imagine we would keep it at the aggregate level) 
> and which we can live with less consistency but gain speed. I think it makes 
> the choice very clear and explicit.

Thanks for confirming!

> 
> I am not clear on what "the ability to loop non-persistent events through the 
> journal" this means exactly. Can you elaborate?

In response to a read request your EP does not immediately respond, rather it 
invokes the currently fictitious method “loopback(myReadEvent){ sender() ! 
theResult }”, which will ensure that the read only occurs after all previously 
processed writes have been properly persisted. This means that you can keep 
full read consistency without having to incur the write performance overhead of 
async=false. It does however depend on the architecture surrounding the EP to 
resend things after a crash, which is why async=false might still make sense in 
some scenarios.

> Lastly views. Currently they are too limiting to be very useful. The idea is 
> a good one, but without being able to project over multiple EP/Ps it is too 
> limiting for anything "real" (At least in our application). Currently in 
> order to have a view that works on EP1 and EP2 I would need to send both sets 
> of events to EP3, re-persist them and create a V over it. So for us, views 
> would only be useful if we could go over multiple EP/P. If the reactive 
> streams would allow that it would be great! To add to that, the stream 
> semantic makes sense for what a View is meant to be (in my eyes). The name 
> View is misleading and makes you think of a snapshot in time. In my eyes, a 
> View should be a way to look into the Stream of persisted events, allowing 
> you to do some sort of processing over it.

Yes, exactly, that is where we should be headed!

Regards,

Roland

> 
> 
> 
> -- 
> >>>>>>>>>> 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.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn


-- 
>>>>>>>>>>      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.

Reply via email to