Thanks for your answer. I got the idea of Akka Persistence but there is another thing i would like to ask. I see distributed transacion is dead end that is why Akka team did not support that.
So the question is that, if an actor got error. the persistent state can be restored, can it be played back? because if we'd like to rollback whatever we have done, we need to play it back somehow. Is it correct? On Mon, Sep 28, 2015 at 7:49 PM, Justin du coeur <[email protected]> wrote: > On Sun, Sep 27, 2015 at 12:55 PM, Bilal Alp <[email protected]> wrote: >> >> I'm a spring user in java and looking for equvalent many things in scala. >> In spring, transaction management is so easy and good. When i look for >> transaction management in akka , I only found that STM. >> >> In Akka 2.3, Transactors are deprecated. I just need to understand the >> logic. There might not be necessary in Akka but i don't know. > > > Basically, transactions (at least in the way they are traditionally used) > scale poorly; despite many years of research and lots of attempts to scale > transaction-based systems up, the architectures usually have problems when > you push them hard. So the Akka team decided, some time ago, that that was > a dead end. > > Well-designed Akka programs generally focus on laying the data out > differently, so that it can be persistent in a more robust way. That's what > Vaughn is getting at with his recommendation to go look at the book. While > it's true that Akka Persistence is storing and restoring the Actor, what I > think you're missing is that the Actor *is* to some degree a bag of data. > Indeed, in many systems that's what the Actors are for: they're primarily > wrappers around mutable data. So storing/restoring the Actor is essentially > the same thing as storing/restoring the data. Instead of transactions for a > data structure, you have that data represented as an Actor; if the Actor is > Persistent, then each time the Actor's state is changed, that change is > recorded in a way that can be played back later. > > Keep in mind, it's not a trivial translation -- you don't necessarily just > take the same data structure, wrap it in an Actor, and *poof* it all works. > Rather, using Akka effectively in a complex application requires digging > into your data and thinking about how the elements relate to each other and > how they should be encapsulated. Once you get the hang of that, though, > much of scalability becomes a lot more straightforward... > > -- >>>>>>>>>>> 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. -- >>>>>>>>>> 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.
