STM deprecation in 2.3

[te...@kevangus.com]

Hi,

Firstly, hello, I'm new to this group and to Akka.

I'm designing a system using Akka from Java. Part of the system has a transactional requirement where I need to update the data held by several actors together or not at all.

I've been looking at the STM documentation for 2.2.3 and think that Transactors will be the best way to implement this.

However, I have just read the 2.3 migration guide and it seems that this whole area is to be deprecated. Also the STM section has been removed from the 2.3 docs.

There isn't really an explanation in the guide and so I am just wondering why this is happening. Is an alternative method recommended to fulfil these requirements?

Cheers,

Kevin

[Patrik Nordwall]

Hi Kevin,

On Fri, Feb 21, 2014 at 12:05 PM, <te...@kevangus.com> wrote:

Hi,

Firstly, hello, I'm new to this group and to Akka.

welcome

 

I'm designing a system using Akka from Java. Part of the system has a transactional requirement where I need to update the data held by several actors together or not at all.

I've been looking at the STM documentation for 2.2.3 and think that Transactors will be the best way to implement this.

I suggest that you use one actor as the consistency boundary. That doesn't mean you have to structure all code into one actor. You can delegate to other classes, and you can have other actors performing work and collecting the sub-results, and then finally when everything is ready perform the update in one actor.

 

However, I have just read the 2.3 migration guide and it seems that this whole area is to be deprecated. Also the STM section has been removed from the 2.3 docs.

There isn't really an explanation in the guide and so I am just wondering why this is happening. Is an alternative method recommended to fulfil these requirements?

The main reasons are that it is not scalable and distributable.

For local usage you can use STM, but you don't need the Akka abstractions for that.

/Patrik

 

Cheers,

Kevin

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[te...@kevangus.com]

Hi Patrik,

 

welcome

Thanks!

 

I suggest that you use one actor as the consistency boundary. That doesn't mean you have to structure all code into one actor. You can delegate to other classes, and you can have other actors performing work and collecting the sub-results, and then finally when everything is ready perform the update in one actor.

 

Currently I have a set of actors that each look after a single document. By look after, I mean they let other actors read the data and receive updated revisions from another system.

If I want to update say 5 of these documents in a single transaction then are you suggesting I have one actor responsible for all 5?

Cheers,

Kevin

[√iktor Ҡlang]

Sounds like you might want to use Agents instead of Transactors. But YMMV

--

>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

√

———————

Viktor Klang

Chief Architect - Typesafe

Twitter: @viktorklang

[Justin du coeur]

On Fri, Feb 21, 2014 at 10:49 AM, <te...@kevangus.com> wrote:

If I want to update say 5 of these documents in a single transaction then are you suggesting I have one actor responsible for all 5?

Think of it this way: if you want to update all 5 of them in the same transaction, that implies that there is *some* semantic relationship that ties them all together -- a higher-level collection, or a common User, or something of the sort.  The best way to handle this situation in Akka is typically to represent that relationship as an Actor, and put the transactional update in there.

Remember, Actors don't have to be mutually-exclusive, and interesting Actor systems are rarely single-level.  It's very common to have a hive of cooperating Actors working together, in charge of different semantic aspects of a complex problem...

[te...@kevangus.com]

Hi Viktor,

I looked at agents but their participation in transactions is also deprecated:

http://doc.akka.io/docs/akka/2.3.0-RC4/java/agents.html#Deprecated_Transactional_Agents

Kevin

[bryan hunt]

I'm glad to see a project cleaning up the API ecosystem, rather than adding more and more bloat .

I always felt the Akka STM extensions were overkill and overly complex.