In the past, I've devoted a ton of time and code to making distributed transactions (kind of) work. I eventually saw the error of my ways.
This paper is a good place to start: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf atomly On Fri, May 13, 2016 at 1:17 PM, Roland Kuhn <[email protected]> wrote: > Hi Robert! > > 13 maj 2016 kl. 19:37 skrev kraythe <[email protected]>: > > 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/ >>>>> >>>>>>>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> √ >>>> >>> >>> -- >>> >>>>>>>>>> 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. >>> >> > -- > >>>>>>>>>> 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. > > > -- > >>>>>>>>>> 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. > -- >>>>>>>>>> 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.
