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 <patrik.nordw...@gmail.com> 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 >>> <https://github.com/akka/akka/issues/15640>. >>> >>> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski <kt...@typesafe.com> >>> 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 <ander...@gmail.com> >>>> 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 <http://akka.io/> @ Typesafe <http://typesafe.com/> >>>> >>>> JOIN US. REGISTER TODAY! >>>> <http://event.scaladays.org/scaladays-sanfran-2015> >>>> Scala <http://event.scaladays.org/scaladays-sanfran-2015> >>>> Days <http://event.scaladays.org/scaladays-sanfran-2015> >>>> March 16th-18th, <http://event.scaladays.org/scaladays-sanfran-2015> >>>> San Francisco <http://event.scaladays.org/scaladays-sanfran-2015> >>>> >>>> -- >>>> >>>>>>>>>> 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 <http://typesafe.com/> - Reactive apps on the JVM >>> Twitter: @patriknw >>> >>> [image: Scala Days] <http://event.scaladays.org/scaladays-sanfran-2015> >>> >>> -- >>> >>>>>>>>>> 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. >>> >> >> -- >> >>>>>>>>>> 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 <http://typesafe.com/> - Reactive apps on the JVM > Twitter: @patriknw > > [image: Scala Days] <http://event.scaladays.org/scaladays-sanfran-2015> > > -- > >>>>>>>>>> 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 a topic in the > Google Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/Nak464Srj-U/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- Studying for the Turing test -- >>>>>>>>>> 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.
