https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong Comments en-us Copyright 2026 Atomikos BVBA Wiki Administrator [webmaster@atomikos.com] The contributing authors of Atomikos Atomikos /Main/WebHome https://www.atomikos.com/pub/System/ProjectLogos/foswiki-logo.png https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong#comment82 How to leverage Atomikos in the cloud « blog.atomikos.com 2011-06-04T09:24:14Z How to leverage Atomikos in the cloud « blog.atomikos.com [...] Luckily, the solution to the problem can be as simple as outlined in our solution to the CAP problem. [...] https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong#comment10 Guy 2008-12-18T14:14:00Z Guy Hi, Actually, what I propose is similar to optimistic locking (used in Hibernate, and in most web applications anyway): updates in the queue are indeed based on some "snapshot" of the data and are applied afterwards (when that data might have changed already). This is also how many web applications work - only there the HTTP session plays the role of the 'queue'. This technique works pretty well except if you have 'hot spot' data - meaning data that changes extremely frequent due to high concurrency. There has been extensive research on this (just google for "optimistic locking" - it has been a while since my research days;-) Guy https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong#comment9 Ender 2008-12-18T12:08:00Z Ender Hi Guy, I was curious, how realistic would this solution be? As I understand it, when you process an update from the queue, the version of the database changes, and hence all the other updates in the queue (who would have a different version number) are rejected, so you would have a lot of rejected updates, which would mean a lot of emails to send to customers to tell them to place their order again. Or am I misunderstanding something? Regards https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong#comment8 Anonymous 2008-12-01T11:24:00Z Anonymous Hi Guy, <br />I don&apos;t like to be anonymous (anonymous said…) My name is Paul Perez, my email is paul.perez@pymma.com. As you said The key point on CAP theorem is the "At the same time" It looks like the Heisenberg uncertainty principle, more you approach quantum size more the Heisenberg principle is accurate. With the CAP theorem, more Partitioned is your system, less you can get A&P at the same time. Best regards PPe I had like you pattern on TCC. I try to implement it with BPEL orchestration. Are there technical sample on that topic. thanks (on my email please) https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong#comment7 Guy 2008-11-10T16:10:00Z Guy Hi Paul, Thanks. You are right, the important notion seems to be "at the same time". It's just that that notion seems flexible if you have the option to be asynchronous (which I assume is not easily the case for distributed caches). However, I do think it is possible to present a suite of algorithms that offer different characteristics and qualities of service. That is what I intend to do in the near future - if time allows. https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong#comment6 Anonymous 2008-11-10T13:10:00Z Anonymous Hello Guy, Thanks for your very interesting papers on transaction. The interest of the CAP theorem is to say that Consistency, Availability and partitioning cannot be reach perfectly AT THE SAME TIME. More the partitioning is important more the CAP theorem becomes accurate. I have been working for many years on distributed cache issues and when our customers want to share datacache between London, New York and Tokyo, the CAP theorem becomes fundamental. It is easy to say we can get C.A.P at the same time when all your device are at the same place and the Partitioning is weak. Best regards Paul Perez