On Thu, Mar 13, 2014 at 9:38 AM, Roger Alsing <[email protected]> wrote:
> Should we stop thinking about transactions as something binary and > instant, that either succeeds or fails here and now? > I am only lurking. But I would argue that the notion of something happening in multiple places at the same time (a distributed transaction) is a physical impossibility that can only be emulated incompletely and at great cost. Things can only happen "at the same time" if they also happen "at the same place". And since computers operate at nearly the speed of light, even two cores on the same die are not "at the same place". At least this is my laymans understanding of what I think roland means. And instead reason about this more as real world processes, where a > transaction can be very long running. > e.g. if I send an invoice to a customer and they don't pay, I need to send > reminders and if the money still havent arrived after x days, the > transaction fails and I have to issue some sort of new process to collect > my money. > And if it turns out eventually that the customer actually did pay, but > there was a problem with the transfer via the bank or whatever, then I have > to issue a compensating command to deal with it since it was not the > customers fault. > > That is, just like Akka deals with failure on a technical level via > supervisors, we need to deal with failure/exceptional events in the actual > domain logic also. > > //Roger > > > > Den onsdagen den 12:e mars 2014 kl. 19:28:42 UTC+1 skrev Justin du coeur: > >> Correct -- this is totally routine in fraud situations. >> >> (I spent much of the past five years working on fraud-detection code. >> The biggest thing I learned is that the financial system isn't even >> *remotely* as atomic as any modern programmer would expect. It isn't just >> that there are race conditions in the overall architectures -- it is that >> those races are often *days* long...) >> >> >> On Mon, Mar 10, 2014 at 5:16 PM, Haoyi Li <[email protected]> wrote: >> >>> > Bank account transfers are not implemented using (distributed) >>> transactions by real banks, that is just an academic ivory tower example >>> ;-) In reality the bank will create a transfer command which is passed from >>> system to system, using safe hand-off techniques (i.e. the money really is >>> "in flight" for a while). If things go wrong, compensating commands are >>> injected which put the money back into the original account. >>> >>> In fact, when you "roll back" a bank account transaction, the bank may >>> just give you money out of its own pocket if the guy you transacted to has >>> taken the money out of an ATM in cash and fled the country. >>> >>> >>> On Mon, Mar 10, 2014 at 2:09 PM, Roland Kuhn <[email protected]> wrote: >>> >>>> >>>> 10 mar 2014 kl. 21:39 skrev Rob Nikander <[email protected]>: >>>> >>>> On Monday, March 10, 2014 5:21:48 AM UTC-4, Björn Antonsson wrote: >>>> >>>>> >>>>> The reason that Akka is moving away from transactions and doesn't >>>>> provide out of the box support for distributed transactions is that they >>>>> perform poorly in real life and promote a thinking that leads to a non >>>>> scaling design. >>>>> >>>>> To build systems without distributed transactions you need to apply a >>>>> different way of thinking about your systems. A good read on the subject >>>>> is >>>>> this Position Paper by Pat Helland: Life beyond Distributed >>>>> Transactions<http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf> >>>>> . >>>>> >>>> >>>> Is there an example somewhere of how to do a bank account transfer, >>>> using this different way of thinking? Or should I just stay away from Akka >>>> if I need transactions of this sort? >>>> >>>> >>>> Bank account transfers are not implemented using (distributed) >>>> transactions by real banks, that is just an academic ivory tower example >>>> ;-) In reality the bank will create a transfer command which is passed from >>>> system to system, using safe hand-off techniques (i.e. the money really is >>>> "in flight" for a while). If things go wrong, compensating commands are >>>> injected which put the money back into the original account. >>>> >>>> In the end there is no way to stay away from the principles which make >>>> Akka seem different to you: distributed transactions do not really exist, >>>> they are always a slightly leaky illusion; that lies in the nature of >>>> distributed systems. You might want to check the CAP theorem (don't trust >>>> the wikipedia page) and Eric Brewer's follow-on >>>> article<http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed> >>>> (he >>>> discusses ATMs as well). >>>> >>>> Regards, >>>> >>>> Roland >>>> >>>> >>>> Rob >>>> >>>> -- >>>> >>>>>>>>>> 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 <http://typesafe.com/> - Reactive apps on the JVM. >>>> twitter: @rolandkuhn >>>> <http://twitter.com/#!/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. >>>> >>> >>> -- >>> >>>>>>>>>> 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. > -- >>>>>>>>>> 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.
