We are removing all Akka Persistence modules for Akka 1.1
Jonas Bonér
We have after much thinking, discussions and analysis decided to drop support for the Akka Persistence Modules. It is part of Akka 1.0, but deprecated and will be removed for Akka 1.1. It will also be moved out of the Akka Modules repository and not maintained by the Akka Team any longer. This is a pretty radical decision and might come as a surprise to most people. We hope to not offend or disrespect anyone of all the great developers that have been contributing code and ideas to these modules. But we strongly believe that it is the right thing to do and will be a good thing for Akka going forward. Please take the time to read the email in its entirety. We will try to explain why and the reasoning behind the decision.
Background
When Akka Persistence modules(s) was started it was intended as a durable storage for STM, combining the two would give the user ACID, ACI from STM and D from the underlying storage solution. It was an experiment starting with a couple of databases which have now grown into a large set of modules supporting many different databases, all with different semantics and guarantees for ACIDness. In theory it might sound like a good idea to have a single transaction layer on top of so many different databases.The problem
However, we have discovered that it gives an illusion of safety that is different for each storage and we simply cannot guarantee that it’s crash-proof. There have been many issues with both which guarantees it can give and which semantics it has in different situations. It has proven to be almost impossible to build a single abstraction layer that deals with all these different models for ACID.Secondly, people are using the persistence modules as an interface to NoSQL storage, without needing the STM. This can be confusing and easily lead to a misunderstanding of what is possible and the original intentions.
Detailed analysis
No failure atomicity:
Placement of the items on the nosql store is not atomic. So it could be that when a transaction fails (for whatever reason) some of the nosql puts are already executed. The abort of the stm transaction is not going to roll these changes back. This problem is increased even more by the optimistic nature of STM (and even more with the speculative behavior if enabled) which can lead to multiple retries (that is why there is a max retry limit since we know that a transaction can be retried). Part of these problems can be solved by putting the stm in a non consistent (read committed isolation level) in combination with a lock on all reads (can be a less expensive read lock). But locking reduces concurrency, causes more overhead and the with the reduced isolation level, the added value of stm is questionable.No consistency:
STM out of the box provides a very high level of read consistency (by default the snapshot isolation level is provided and is exactly the same as the Oracle version of Serialized). Example, if there are 100 refs all initialized with the value 0 and there is an update transaction that increases all refs atomically and there are reading transactions, they will always see exactly the same value for all references (whatever the value may be). With NoSQL there doesn’t exist such a high level of read consistency since their designs go in the exact opposite direction (eventual consistency). So the consistency models of STM and NoSQL are extremes. It is possible to put the STM in a lower consistency mode (e.g. read committed/repeatable read), but that make STM much much harder to reason about (race problems).Another big difference is that write consistency is dead simple with STM, but with NoSQL this can even be something of a challenge. So even the write consistency models differ and can cause subtle problems if not dealt with correctly.
No isolation:
The STM provides isolation in memory for a specific JVM. But if the same nosql ‘record’ is used by multiple machines, the STM is not going to be able to provide any isolation. Even locks acquired on one machine on STM level will not translate in locks on the NoSQL store. To get this to work, you need something like distributed STM.Even on a single machine there could be issues of the same NoSQL records are accessed by any other means than the STM.
Lost updates:
If there are multiple machines changing the data, there is no optimistic locking on writing the data. So if data of version X is read, another transaction changes it to X+1 and the first transaction commits, the resulting version is X+1 and no optimistic locking conflict is thrown. If you use a or mapper like hibernate for example and activate optimistic locking, it will detect and abort the transaction. In our case, the lost update is not detected and the essential leads to a permanent inconsistent state since it will not be repaired (afaik) by a developer.I know that Brendan McAdams (of Mongo) is working on some functionality, we both figured out that some essential operations (like acquiring a lock) was not going to make it in Mongo.
Possible future solutions:
To combine STM and distribution/storage, you need to have a solution where the approaches are compatible. E.g. if you look at Terracotta or Gigaspaces, they provide the basic operations to satisfy the guarantees needed for Distributed STM. Failure atomicity (transactions), various levels of locking, isolation etc.Thanks for your understanding,
Jonas Bonér
Viktor Klang
Peter Veentjer
Peter Vlugter
--
Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
blog: http://jonasboner.com
twtr: @jboner
Jonas Bonér
Brendan W. McAdams
I should clarify that from the Mongo end there are safe ways to get the desired behavior but not with locking; (we have effective tools for handling ABA, etc). I may evaluate integrating an Akka friendly persistence layer to the Mongo Scala driver (Casbah) to bridge some of the gap created by Akka migrating away from it.
Ive been working lately on ways to improve Akka's Mongo Persistence integration and it is just too hard to make it all fit. This is a growing problem in the NoSQL space.
Frameworks are adding layers that create a unified api on top of all NoSQL containers and as a result we lose much of what is strong about each container. or worse accentuate what is weak. Mongo is not cassandra. Or riak. Or redis. And vice versa.
Treating them all the same is a nightmare on all ends to maintain and I applaud a sound decision here to short circuit this.
As for those who want Mongo+ Akka to play nicely together feel free to contact me: Making Scala and Mongo work together is my dayjob, after all. (By night Im a crime fighting superhero. Or was that a viking? I can never remember)
-b
> Dear hakkers.
>
> We have after much thinking, discussions and analysis decided to drop
> support for the Akka Persistence Modules. It is part of Akka 1.0, but
> deprecated and will be removed for Akka 1.1. It will also be moved out of
> the Akka Modules repository and not maintained by the Akka Team any longer.
> This is a pretty radical decision and might come as a surprise to most
> people. We hope to not offend or disrespect anyone of all the great
> developers that have been contributing code and ideas to these modules. But
> we strongly believe that it is the right thing to do and will be a good
> thing for Akka going forward. Please take the time to read the email in its
> entirety. We will try to explain why and the reasoning behind the decision.
>
> durable storage for STM, combining the two would give the user ACID, ACI
> from STM and D from the underlying storage solution. It was an experiment
> starting with a couple of databases which have now grown into a large set of
> modules supporting many different databases, all with different semantics
> and guarantees for ACIDness. In theory it might sound like a good idea to
> have a single transaction layer on top of so many different databases.
> that is different for each storage and we simply cannot guarantee that it’s
> crash-proof. There have been many issues with both which guarantees it can
> give and which semantics it has in different situations. It has proven to be
> almost impossible to build a single abstraction layer that deals with all
> these different models for ACID.
>
> Secondly, people are using the persistence modules as an interface to NoSQL
> storage, without needing the STM. This can be confusing and easily lead to a
> misunderstanding of what is possible and the original intentions.
> distribution/storage, you need to have a solution where the approaches are
> compatible. E.g. if you look at Terracotta or Gigaspaces, they provide the
> basic operations to satisfy the guarantees needed for Distributed STM.
> Failure atomicity (transactions), various levels of locking, isolation etc.
>
> Thanks for your understanding,
>
> Jonas Bonér
>
> Viktor Klang
>
> Peter Veentjer
>
> Peter Vlugter
>
>
> --
> Jonas Bonér
>
> Specialist at Large
> work: http://scalablesolutions.se
> code: http://akka.io
> blog: http://jonasboner.com
> twtr: @jboner
>
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>
Jonas Bonér
Peter Veentjer
√iktor Klang
I agree, any persistence APIs should compliment the underlying storage solution. Not accentuate weak spots and obscure strong points.
On Feb 17, 2011 4:06 AM, "Brendan W. McAdams" <bre...@10gen.com> wrote:I should clarify that from the Mongo end there are safe ways to get the desired behavior but not with locking; (we have effective tools for handling ABA, etc). I may evaluate integrating an Akka friendly persistence layer to the Mongo Scala driver (Casbah) to bridge some of the gap created by Akka migrating away from it.
Ive been working lately on ways to improve Akka's Mongo Persistence integration and it is just too hard to make it all fit. This is a growing problem in the NoSQL space.
Frameworks are adding layers that create a unified api on top of all NoSQL containers and as a result we lose much of what is strong about each container. or worse accentuate what is weak. Mongo is not cassandra. Or riak. Or redis. And vice versa.
Treating them all the same is a nightmare on all ends to maintain and I applaud a sound decision here to short circuit this.
As for those who want Mongo+ Akka to play nicely together feel free to contact me: Making Scala and Mongo work together is my dayjob, after all. (By night Im a crime fighting superhero. Or was that a viking? I can never remember)
-b
On Feb 17, 2011 3:52 AM, "Jonas Bonér" <jo...@jonasboner.com> wrote:
> Dear hakkers.
>
> We have ...
> BackgroundWhen Akka Persistence modules(s) was started it was intended as a
> durable storage for STM, combining the two would give the user ACID, ACI
> from STM and D from th...
> The problemHowever, we have discovered that it gives an illusion of safety
> that is different for each storage and we simply cannot guarantee that it’s
> crash-proof. There ...
> Detailed analysisNo failure atomicity:Placement of the items on the nosql
> store is not atomic. So it could be that when a transaction fails (for
> whatever reason) some of...
--
You received this message because you are subscribed to the Google Groups "Akka User List" grou...
Scott Clasen
On Feb 17, 4:26 am, √iktor Klang <viktor.kl...@gmail.com> wrote:
> I agree, any persistence APIs should compliment the underlying storage
> solution. Not accentuate weak spots and obscure strong points.
>
Raymond Roestenburg
--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--
Raymond Roestenburg
Pekka Mattila
but we faced too many problems with it. Now we are happily using lower
level Api for Redis and everything works like a charm.
Best Regards,
Pekka
On Feb 18, 10:45 am, Raymond Roestenburg
√iktor Klang
Great to hear that, all the feedback I've heard on this topic has been very positive.
On Feb 20, 2011 9:10 AM, "Pekka Mattila" <pe...@starduckstudios.com> wrote:
Great decision. For example, we tried to use Akka's Redis integration
but we faced too many problems with it. Now we are happily using lower
level Api for Redis and everything works like a charm.
Best Regards,
Pekka
On Feb 18, 10:45 am, Raymond Roestenburg
<raymond.roestenb...@gmail.com> wrote:
> +1 on the decision.
>
>
>
>
>
>
>
>
>
> On Thu, Feb 17, 2011 at 9:51 AM, Jonas Bonér <jo...@jonasboner.com> wrote:
> > Dear hakkers.
>
> >...