Hi Robert, I feel your pain, but unfortunately the pain is real as it results from a fundamental conflict: if the users expect the system to behave (strictly) serializable then the system cannot scale or be highly available because it is limited by the CAP theorem. Without giving up this expectation there is no technical trick you can pull that would magically fix this. (scary interjection: actual databases have bugs and are not actually serializable—also for performance reasons)
In practice, though, users are already used to inconsistencies—although they clearly prefer them to be rare and small. This is what Viktor was pointing out: why is it acceptable that a transaction can be broken by external parties, but unacceptable that it can be broken by local failure? If both of these are rare, then it shouldn’t matter, but there is this mindset that failure is unacceptable which prevents you from progressing. Eventual consistency does not have to mean that people will see inconsistent analytics all the time, but the effort that is needed for implementing those analytics depends on both the rate at which the system accepts changes, the inconsistency window (typically some milliseconds), and the leniency of the observers. If your system runs 1 transaction per second and the inconsistency window is 1ms then roughly 1 in 1000 observations may see the effects of a partially executed transaction (extremely simplified maths, of course). You can build your analytics such that they look at a snapshot to make them fully consistent, but that amounts to reconstructing the system’s state from the logs for each query—is that really necessary? (it would also require your logs to carry transaction IDs and consist of commutative operations, and the analytics would not necessarily represent a real intermediate state of the system, etc.) In summary, you cannot wave your wand and make a traditional transaction-based system distributed, performant and highly available without needing to touch any of its users. If you want to integrate such a system with other concerns that you model as Actors, then the best you can do is to encapsulate and represent the whole system in a (pool of) actor(s) that use the horrible blocking transaction-offering APIs that you are forced to use; just make sure to configure them to run on a separate dispatcher and you should be fine. For further reading I also recommend «A Life Beyond Distributed Transactions», which describes that objects across which you need transactional behavior need to be local (i.e. cannot be distributed) but typically you can separate several kinds of objects so that some form of distribution becomes possible within these constraints. Regards, Roland > 13 maj 2016 kl. 21:29 skrev kraythe <[email protected]>: > > I definitely appreciate your time and point of view Rolland but how do I > solve this without transactions? Basically I have a set of things that I have > to update as a unit. I have to alter record in one table and write records to > two more tables. I would love to completely purge the system of the need for > transactions. I would love to do that to make it more scalable and > performant. What I cant figure out is how to get around it. In an app like > twitter or facebook, its pretty simple. If a post or tweet gets lost, no > biggie. In a financial oriented system I need 100% certainty that either the > Wallet records were written and entry updated or that neither of those things > happen. > > Thats a critique i have had in my research of Akka and its applicability to > systems I work on. The examples, use cases and demos seem to be systems > unlike anything I actually have worked on in my career. I have never had to > write a blog engine or a messaging app. Every one of the apps I work on is > from the point of view of one or another part of the financial sector where > you are moving people's money around and they get CRANKY when you lose it. > For example, if a user wants to withdraw 200 from the bank you have to make > sure you record the withdrawal and decrement their account as well. We cant > decrement the account and "fail" to record the withdrawal. They both have to > happen or nothing at all. Here is where we use transactions to talk to the > db. > > BEGINE TRANSACTION; > UPDATE account SET balance = 800; > INSERT INTO records (id, .... ) VALUES (.....) > COMMIT TRANSACTION; > > None of those are optional, we cant give the user the money if the node > registering the withdrawal records is down, nor can we sent a big guy named > Vinny to go collect the money if the withdrawal record is lost. We have to do > an all or nothing issue. > > Every time I try to transition to the Reactive - Akka way of doing things I > hit this wall. The demos don't help because they are trivial applications and > I cant sell a conversion until I can answer this question. Each time I come > and try to make such posts, I end up at an impasse, give up and go on doing > it the old way, realizing that I am not building a massively scalable > application. I have to sell the whole issue to my executives. I cant tell > them that their analytics are going to need to be completely rebuilt so I can > implement a journaled DB nor can I tell them "we will have eventual > consistency when dealing with wallets." "Eventual?" They will ask. Customers > get darn cranky when things are off by even a cent. Eventual just wont cut > it. > > I would LOVE a solution to this problem. I would love to be able to march > into my company and say "I can solve all of our scalability problems." But > until I overcome this issue, I am stuck. > > Any Advice? Any Options? > > Thanks > > -- Robert > > > On Friday, May 13, 2016 at 1:17:16 PM UTC-5, rkuhn wrote: > Hi Robert! > >> 13 maj 2016 kl. 19:37 skrev kraythe <kra...@ <>gmail.com >> <http://gmail.com/>>: >> >> Well we dont have to deal with that. Its so rare that its not in the >> software. Security team would deal with that. > > This is exactly the point: what is the probability that the system crashes > while performing a given transaction? Usually it is extremely small. > > Another consideration is that for atomicity and durability you don’t need > full ACID transactions, you only need a means of ensuring that the logic runs > to completion (which may also be a rollback due to a permanent failure). This > means that using a process manager (cf. «SAGAS» by Hector Garcia–Molina) is a > suitable solution as long as no isolation or consistency concerns enter the > picture, i.e. when eventual consistency is fine. Eventual consistency entails > reaching a consistent state eventually, which usually is good enough. > > The point with “Akka vs. Transactions” is that Akka models distribution, > which is inherently at odds with traditional ACID, therefore you won’t find > an idiomatic solution to your question—if you want ACID you shouldn’t > distribute your objects. > > Regards, > > Roland > >> >> If we had to, I would debit the account based on the amounts that were >> credited in the account. >> >> I know what yo uare getting at but its pretty impossible to bypass the >> notion of a "unit of work which spans domain objects". >> >> -- Robert >> >> On Friday, May 13, 2016 at 8:38:26 AM UTC-5, √ wrote: >> No, I mean if the bank reverses a payment which was previously accepted. >> >> -- >> Cheers, >> √ >> >> On May 13, 2016 3:25 PM, "kraythe" <[email protected] <>> wrote: >> Well currently the system is designed such that the remote transaction >> failing rolls back the transaction. So in this one scenario, that is how it >> is handled. However, this particular use case could be redesigned to say: >> >> 1) When user wins prize, write transactions and change state to >> TRANSACTIONS_WRITTEN >> 2) When transactions in CREATED state, increment wallet and move >> transactions to CREDITED state. >> >> Essentially powering on everything like it has state. However, you notice we >> still have to change two objects which could nominally be independent actors >> at the same time and have them all work or none at all. Furthermore we will >> have to have a process that combs the system constantly looking for objects >> that are stuck in a state because a node died or something happened so as to >> not orphan objects in the pipeline. >> >> HOWEVER, there are other ACID situations in the platform that cannot be >> designed that way. Situations where we really need modifications to several >> objects to all happen or none at all. So I am back into the question of a >> general paradigm in an Akka platform. >> >> On Thursday, May 12, 2016 at 11:36:25 PM UTC-5, √ wrote: >> What will you do if the bank reverses the payment? >> >> On Thu, May 12, 2016 at 11:41 PM, kraythe <[email protected] <>> wrote: >> I have a system that is a traditional DB centric app for the most part. >> However the data is loaded in a memcache for speed and ease of use. What I >> would be interested in doing is migrating the app to a actor centric >> paradigm. Also keep in mind that I speak Scala but my colleagues don't so I >> would have to be stuck in Java world. The use case I can't get past is this. >> >> A user has an entry in a competition and if they win the competition they >> get a prize. When we want to award that user a prize we need to go update >> the entry noting it has been paid, write multiple transactions to the system >> to track the payment and update their wallet with the prize. Now all of >> these things have to happen or none of them have to happen. >> >> It would make sense to make the entry an actor as well as the wallet. The >> transactions are a bit more questionable. What I can't figure out is how I >> can change all of those actors and fail if anything goes wrong. There is no >> option to think that we can avoid ACID here. >> >> I have been researching on google and this group and there is a lot of >> information but most is dated and conflicting. Any ideas to help out? >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> >> >>>>>>>>>> Check the FAQ: >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> >> >>>>>>>>>> Search the archives: >> >>>>>>>>>> https://groups.google.com/group/akka-user >> >>>>>>>>>> <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 https://groups.google.com/group/akka-user >> <https://groups.google.com/group/akka-user>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> >> -- >> Cheers, >> √ >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> >> >>>>>>>>>> Check the FAQ: >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> >>>>>>>>>> <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+...@ <>googlegroups.com <http://googlegroups.com/>. >> To post to this group, send email to akka...@ <>googlegroups.com >> <http://googlegroups.com/>. >> Visit this group at https://groups.google.com/group/akka-user >> <https://groups.google.com/group/akka-user>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> >> >>>>>>>>>> Check the FAQ: >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> >>>>>>>>>> <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 https://groups.google.com/group/akka-user >> <https://groups.google.com/group/akka-user>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/akka-user > <https://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
