Re: [akka-user] Re: akka-persistance - nested persist

[Patrik Nordwall]

I don't think we strongly recommend against it. Use it if it simplifies
your use case.

For the record, it was implemented by this PR:
https://github.com/akka/akka/pull/17828

On Fri, Dec 2, 2016 at 11:00 PM, Aditya Prasad  wrote:

> Now that nested persist works, is it still strongly suggested not to nest
> persists? The way I see it, there are a few approaches:
>
>1. Nested persists. In this model, my handler does (a) applyEvent
>(state change) and (b) postApply (take action, including more persisting).
>This allows me to structure my postApply handler in a readable fashion, so
>it's clear what's triggering what.
>2. Send myself a command. The drawback is that state could change in
>between and so I have to handle failure cases which are sort of spurious.
>3. Simulate all downstream effects before persisting. The benefit
>(versus both #1 and #2) is that it prevents some weird intermediate states
>(e.g., on replay), and the drawback is that I have to simulate an arbitrary
>number of steps, which can become very unreadable.
>
> What are the main drawbacks of nesting?
>
> Cheers,
> A
>
> --
> >> 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 https://groups.google.com/group/akka-user.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: akka-persistance - nested persist

[Patrik Nordwall]

On Tue, Mar 10, 2015 at 3:03 PM, Manuel Bernhardt <
bernhardt.man...@gmail.com> wrote:

> Hi!
>
> And sorry for the late reply. We discussed this at LambdaDays with Konrad,
> it's only normal this doesn't work. I'm exploring other alternatives for
> simulating the change in the most lazy possible manner.
>
> A quick clarification: I'm working on a reservation system, and quite a
> number of events can have an impact on available quota. When one of those
> events is persisted I need to look up the impact the quota change has on a
> waiting-list, and promote waiting-list entries accordingly. That should
> happen before any other reservation could slip in and fetch a spot that
> would have been assigned to one of the waiting-list entries.
>
> I am fully aware that the correct way is to simulate what is going to
> happen before persisting any of those events and persist the event and
> eventual promotions of the waiting-list entries in one go.
>
> Out of curiosity (not that my case requires it, but I am wondering about
> it nonetheless): is there a way to persist a batch of events that are
> connected, so that if the Nth isn't persisted we get to roll back on the
> whole batch and don't end up with inconsistent state?
>

The documented behaviour is: "All events that are persisted in context of a
single command are written as a single batch to the journal (even if
persist is called multiple times per command). The recovery of a
PersistentActor will therefore never be done partially (with only a subset
of events persisted by a single command)."

We have not enforced that in the TCK, so I'm not sure all journals
implement it that way. We will think about this more and consider if we
need some other atomic batch concept. See issue:
https://github.com/akka/akka/issues/15377


>
> Thanks,
>
> Manuel
>
>
> On Mon, Mar 2, 2015 at 9:06 AM, Patrik Nordwall  > wrote:
>
>> I think this is a known issue 
>> .
>>
>> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski 
>> wrote:
>>
>>> Hi Manuel,
>>> as discussed on LambdaDays today: this won't work, because what
>>> guarantees persist() is meant to give.
>>> Instead you could become() and then do things inside there, or send
>>> other commands to yourself to which the actor should react.
>>>
>>> On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
>>> wrote:
>>>
 I am not sure I understand what you are trying to accomplish. Don't you
 know the consequences of the state change before you do a persist? You
 could calculate all the changes you want to do, and them persist them in
 order...

 Regards,

 Anders

 fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:

> Hi,
>
> I'm in a situation where it would be lovely to be able to do a "nested
> persist", i.e.:
>
> persist(SomeEvent)(handle)
>
> ...
>
> def handle = {
>   case SomeEvent =>
> changeState()
> stateChangeConsequences().foreach { _ =>
>   persist(SomeOtherEvent)(handle)
> }
> }
>
> According to a quick experimentation this does not seem to be quite
> working. The reason I am looking for this kind of perhaps not entirely
> ethical behaviour (commands should create events, not event creating
> events, if I got things correctly) is that I need SomeOtherEvent to be
> fired right away without giving the chance to someone else to come in (I'm
> building a reservation system and this part is about waiting-list 
> handling).
>
> The other possible option would be to simulate state change and revert
> it before persisting SomeEvent, but it would considerably complicate the
> flow (the example above is oversimplified and there's already a simulation
> going on).
>
> Is there any recommended approach for this kind of behaviour?
>
> Thanks,
>
> Manuel
>
>
  --
 >> 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.

>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso' Malawski
>>> Akka  @ Typesafe 
>>>
>>> JOIN US. REGISTER TODAY!
>>> 
>>> Scala 
>>> Days 
>>

Re: [akka-user] Re: akka-persistance - nested persist

[Greg Young]

In terms of engines supporting. Event Store as an example supports
transactions between multiple requests that could support exactly this.

eg

begin transaction
write
write
write
write
commit / rollback

and it can be between multiple actors so long as the transaction id is
shared between them. There is a limitation that they must be in the same
stream but thats easy to work around.

That said we have considered removing this functionality as its not so much
something you should be doing.




>From a more general level on the problem (in terms of interactions leaving
out all technology). Could you wait until the coordination is done before
ack/naking the end user and use a coordinator/process manager to coordinate
the work internally rolling back if need be?

Cheers,

Greg

On Tue, Mar 10, 2015 at 4:57 PM, Patrik Nordwall 
wrote:

>
>
> On Tue, Mar 10, 2015 at 3:03 PM, Manuel Bernhardt <
> bernhardt.man...@gmail.com> wrote:
>
>> Hi!
>>
>> And sorry for the late reply. We discussed this at LambdaDays with
>> Konrad, it's only normal this doesn't work. I'm exploring other
>> alternatives for simulating the change in the most lazy possible manner.
>>
>> A quick clarification: I'm working on a reservation system, and quite a
>> number of events can have an impact on available quota. When one of those
>> events is persisted I need to look up the impact the quota change has on a
>> waiting-list, and promote waiting-list entries accordingly. That should
>> happen before any other reservation could slip in and fetch a spot that
>> would have been assigned to one of the waiting-list entries.
>>
>> I am fully aware that the correct way is to simulate what is going to
>> happen before persisting any of those events and persist the event and
>> eventual promotions of the waiting-list entries in one go.
>>
>> Out of curiosity (not that my case requires it, but I am wondering about
>> it nonetheless): is there a way to persist a batch of events that are
>> connected, so that if the Nth isn't persisted we get to roll back on the
>> whole batch and don't end up with inconsistent state?
>>
>
> The documented behaviour is: "All events that are persisted in context of
> a single command are written as a single batch to the journal (even if
> persist is called multiple times per command). The recovery of a
> PersistentActor will therefore never be done partially (with only a subset
> of events persisted by a single command)."
>
> We have not enforced that in the TCK, so I'm not sure all journals
> implement it that way. We will think about this more and consider if we
> need some other atomic batch concept. See issue:
> https://github.com/akka/akka/issues/15377
>
>
>>
>> Thanks,
>>
>> Manuel
>>
>>
>> On Mon, Mar 2, 2015 at 9:06 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> I think this is a known issue
>>> .
>>>
>>> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski 
>>> wrote:
>>>
 Hi Manuel,
 as discussed on LambdaDays today: this won't work, because what
 guarantees persist() is meant to give.
 Instead you could become() and then do things inside there, or send
 other commands to yourself to which the actor should react.

 On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
 wrote:

> I am not sure I understand what you are trying to accomplish. Don't
> you know the consequences of the state change before you do a persist? You
> could calculate all the changes you want to do, and them persist them in
> order...
>
> Regards,
>
> Anders
>
> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>
>> Hi,
>>
>> I'm in a situation where it would be lovely to be able to do a
>> "nested persist", i.e.:
>>
>> persist(SomeEvent)(handle)
>>
>> ...
>>
>> def handle = {
>>   case SomeEvent =>
>> changeState()
>> stateChangeConsequences().foreach { _ =>
>>   persist(SomeOtherEvent)(handle)
>> }
>> }
>>
>> According to a quick experimentation this does not seem to be quite
>> working. The reason I am looking for this kind of perhaps not entirely
>> ethical behaviour (commands should create events, not event creating
>> events, if I got things correctly) is that I need SomeOtherEvent to be
>> fired right away without giving the chance to someone else to come in 
>> (I'm
>> building a reservation system and this part is about waiting-list 
>> handling).
>>
>> The other possible option would be to simulate state change and
>> revert it before persisting SomeEvent, but it would considerably 
>> complicate
>> the flow (the example above is oversimplified and there's already a
>> simulation going on).
>>
>> Is there any recommended approach for this kind of behaviour?
>>
>> Thanks,
>>
>> Manuel
>>
>>
>  --
> >

Re: [akka-user] Re: akka-persistance - nested persist

[Manuel Bernhardt]

Hi!

And sorry for the late reply. We discussed this at LambdaDays with Konrad,
it's only normal this doesn't work. I'm exploring other alternatives for
simulating the change in the most lazy possible manner.

A quick clarification: I'm working on a reservation system, and quite a
number of events can have an impact on available quota. When one of those
events is persisted I need to look up the impact the quota change has on a
waiting-list, and promote waiting-list entries accordingly. That should
happen before any other reservation could slip in and fetch a spot that
would have been assigned to one of the waiting-list entries.

I am fully aware that the correct way is to simulate what is going to
happen before persisting any of those events and persist the event and
eventual promotions of the waiting-list entries in one go.

Out of curiosity (not that my case requires it, but I am wondering about it
nonetheless): is there a way to persist a batch of events that are
connected, so that if the Nth isn't persisted we get to roll back on the
whole batch and don't end up with inconsistent state?

Thanks,

Manuel


On Mon, Mar 2, 2015 at 9:06 AM, Patrik Nordwall 
wrote:

> I think this is a known issue .
>
> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski 
> wrote:
>
>> Hi Manuel,
>> as discussed on LambdaDays today: this won't work, because what
>> guarantees persist() is meant to give.
>> Instead you could become() and then do things inside there, or send other
>> commands to yourself to which the actor should react.
>>
>> On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
>> wrote:
>>
>>> I am not sure I understand what you are trying to accomplish. Don't you
>>> know the consequences of the state change before you do a persist? You
>>> could calculate all the changes you want to do, and them persist them in
>>> order...
>>>
>>> Regards,
>>>
>>> Anders
>>>
>>> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>>>
 Hi,

 I'm in a situation where it would be lovely to be able to do a "nested
 persist", i.e.:

 persist(SomeEvent)(handle)

 ...

 def handle = {
   case SomeEvent =>
 changeState()
 stateChangeConsequences().foreach { _ =>
   persist(SomeOtherEvent)(handle)
 }
 }

 According to a quick experimentation this does not seem to be quite
 working. The reason I am looking for this kind of perhaps not entirely
 ethical behaviour (commands should create events, not event creating
 events, if I got things correctly) is that I need SomeOtherEvent to be
 fired right away without giving the chance to someone else to come in (I'm
 building a reservation system and this part is about waiting-list 
 handling).

 The other possible option would be to simulate state change and revert
 it before persisting SomeEvent, but it would considerably complicate the
 flow (the example above is oversimplified and there's already a simulation
 going on).

 Is there any recommended approach for this kind of behaviour?

 Thanks,

 Manuel


>>>  --
>>> >> 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.
>>>
>>
>>
>>
>> --
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka  @ Typesafe 
>>
>> JOIN US. REGISTER TODAY!
>> 
>> Scala 
>> Days 
>> March 16th-18th, 
>> San Francisco 
>>
>> --
>> >> 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/opto

Re: [akka-user] Re: akka-persistance - nested persist

[Patrik Nordwall]

I think this is a known issue .

On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski  wrote:

> Hi Manuel,
> as discussed on LambdaDays today: this won't work, because what guarantees
> persist() is meant to give.
> Instead you could become() and then do things inside there, or send other
> commands to yourself to which the actor should react.
>
> On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
> wrote:
>
>> I am not sure I understand what you are trying to accomplish. Don't you
>> know the consequences of the state change before you do a persist? You
>> could calculate all the changes you want to do, and them persist them in
>> order...
>>
>> Regards,
>>
>> Anders
>>
>> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>>
>>> Hi,
>>>
>>> I'm in a situation where it would be lovely to be able to do a "nested
>>> persist", i.e.:
>>>
>>> persist(SomeEvent)(handle)
>>>
>>> ...
>>>
>>> def handle = {
>>>   case SomeEvent =>
>>> changeState()
>>> stateChangeConsequences().foreach { _ =>
>>>   persist(SomeOtherEvent)(handle)
>>> }
>>> }
>>>
>>> According to a quick experimentation this does not seem to be quite
>>> working. The reason I am looking for this kind of perhaps not entirely
>>> ethical behaviour (commands should create events, not event creating
>>> events, if I got things correctly) is that I need SomeOtherEvent to be
>>> fired right away without giving the chance to someone else to come in (I'm
>>> building a reservation system and this part is about waiting-list handling).
>>>
>>> The other possible option would be to simulate state change and revert
>>> it before persisting SomeEvent, but it would considerably complicate the
>>> flow (the example above is oversimplified and there's already a simulation
>>> going on).
>>>
>>> Is there any recommended approach for this kind of behaviour?
>>>
>>> Thanks,
>>>
>>> Manuel
>>>
>>>
>>  --
>> >> 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.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> Akka  @ Typesafe 
>
> JOIN US. REGISTER TODAY!
> 
> Scala 
> Days 
> March 16th-18th, 
> San Francisco 
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

[image: Scala Days] 

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

Re: [akka-user] Re: akka-persistance - nested persist

[Konrad Malawski]

Hi Manuel,
as discussed on LambdaDays today: this won't work, because what guarantees
persist() is meant to give.
Instead you could become() and then do things inside there, or send other
commands to yourself to which the actor should react.

On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
wrote:

> I am not sure I understand what you are trying to accomplish. Don't you
> know the consequences of the state change before you do a persist? You
> could calculate all the changes you want to do, and them persist them in
> order...
>
> Regards,
>
> Anders
>
> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>
>> Hi,
>>
>> I'm in a situation where it would be lovely to be able to do a "nested
>> persist", i.e.:
>>
>> persist(SomeEvent)(handle)
>>
>> ...
>>
>> def handle = {
>>   case SomeEvent =>
>> changeState()
>> stateChangeConsequences().foreach { _ =>
>>   persist(SomeOtherEvent)(handle)
>> }
>> }
>>
>> According to a quick experimentation this does not seem to be quite
>> working. The reason I am looking for this kind of perhaps not entirely
>> ethical behaviour (commands should create events, not event creating
>> events, if I got things correctly) is that I need SomeOtherEvent to be
>> fired right away without giving the chance to someone else to come in (I'm
>> building a reservation system and this part is about waiting-list handling).
>>
>> The other possible option would be to simulate state change and revert it
>> before persisting SomeEvent, but it would considerably complicate the flow
>> (the example above is oversimplified and there's already a simulation going
>> on).
>>
>> Is there any recommended approach for this kind of behaviour?
>>
>> Thanks,
>>
>> Manuel
>>
>>
>  --
> >> 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.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
Akka  @ Typesafe 

JOIN US. REGISTER TODAY! 
Scala 
Days 
March 16th-18th, 
San Francisco 

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