About Munish Gupta

Munish K Gupta is a senior architect working in a leading IT services company. His experience is in building Online Portals, SaaS Platforms, CRM Solutions and Transaction Processing Systems. He is author of the book - Akka Essentials.

Software Transactional Memory (STM)

The Actor Model is based on the premise of small independent processes working in isolation and where the state can be updated only via message passing. The actors hold the state within themselves, but the asynchronous message passing means there is no guarantee that a stable view of the state can be provided to the calling components. For transactional systems like banking where account deposit and withdrawal need to be atomic, this is a bad fit with an Actor Model.So, if your Akka applications need to be implementing a shared state model and providing a consensual, stable view of the state across the calling components, Software Transactional Memory (STM) provides the answer.
 
 
 
STM provides a concurrency-control mechanism for managing access to shared memory. STM makes use of two concepts – optimism and transactions to manage the shared concurrency control.

  • Optimism means that we run multiple atomic blocks in parallel, assuming there will be no errors. When we are done, we check for any problems. If no problems are found, we update the state variables in the atomic block. If we find problems then we roll back and retry. Optimistic concurrency typically provides better scalability options than any other alternate approaches.
  • Secondly, STM is modeled on similar lines of database transaction handling. In the case of STM, the Java heap is the transactional data set with begin/commit and rollback constructs. As the objects hold the state in memory, the transaction only implements the following characteristics – atomicity, consistency, and isolation.

To manage multiple transactions running on separate threads as a single atomic block, the concept of CommitBarrier is used.
CommitBarrier is a synchronization aid that is used as a single, common barrier point by all the transactions across multiple threads. Once the barrier is reached, all the transactions commit automatically. It is based on the Java’s CountDownLatch.

Akka transactors are based on CommitBarrier, where the atomic blocks of each actor (member) participating are treated as one, big single unit. Each actor will block until everyone participating in the transaction has completed. This means that all the actions executed as part of the atomic blocks by members of the CommitBarrier will appear to occur as a single atomic action even though the members may be spread across multiple threads. If any of the atomic blocks throw an exception or a conflict happens, all the CommitBarrier members will roll back.

Akka provides a construct for coordinating transactions across actors called coordinated.coordinated, which is used to define the transaction boundary in terms of where the transaction starts, and the coordinated.coordinate() method is used to add all the members that will participate in the same transaction context.

Money transfer between two accounts

Let’s take an example and see how the actors can participate in the transactions. We will use the classic example of transfer of funds between two bank accounts . We have an AccountActor that holds the account balance and account number information. It has two operations – credit (add money to the account) and debit (take money away from the account). In addition, we have the TransferActor object that will hold the two AccountActor objects and then invoke the debit and credit operations on the account objects.
To make sure that the money transfer in the account happens in a synchronized way, we need to implement the following:

  • In the account object, the state variable that needs to participate in the transaction should be of transaction reference type.
  • The credit and debit operations in the account object need to be atomic.
  • In the transfer object, the transaction boundary needs to be defined and the account objects need to participate in the same transaction context.
  • In addition, we define the supervisor policy in TransferActor and BankActor to handle the transaction exceptions:

Parts of the post are excerpts from the book – Akka Essentials. For more details on the example, please refer to the book.
 

Reference: Software Transactional Memory (STM) from our JCG partner Munish K Gupta at the Akka Essentials blog.

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


− 1 = seven



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books