ScappShots

A couple of weeks ago I posted a quick example and explanation of a GigaSpaces local transaction.  You can find the post here and get the code here.

In today’s short post I will extend that example to use a distributed transaction.  We’ll do this in two steps: first we’ll break the example; then we’ll fix it.

As a reminder, a GigaSpaces distributed transaction is any transaction that operates on more than one primary space.  In the example code, our client program executed a local transaction when it wrote two instances of TestClass to a single instance remote space.

In that example routing was not a concern because we created the space as unpartitioned, and we did not declare a space routing field. Behind the scenes, however, GigaSpaces selected one (the id field) for us.  You can check this on the Space Browser tab by expanding the GSSimpleTranExample space node, clicking on “Classes”, then clicking on “TestClass”.  The name of Routing Filed will appear on the Classes Info tab just above the table showing the fields (only one in our case) in the class.

Now drop the space using Undeploy Application on the Cluster Runtime tab.  Then recreate it as a partitioned space with two partitions and no backups.  Rerun the client application, and it will fail with this error message:

Exception in thread “main” org.openspaces.core.TransactionDataAccessException: Invalid operation – local transaction spans over multiple spaces – [GSSimpleTranExample_container2:GSSimpleTranExample, GSSimpleTranExample_container1:GSSimpleTranExample] !
You might be using hash based load balancing (partitioned schema) while writing data into multiple spaces and not into a single node.
Please Use Jini Transaction manager with your operations.
; nested exception is net.jini.core.transaction.TransactionException: Invalid operation – local transaction spans over multiple spaces – [GSSimpleTranExample_container2:GSSimpleTranExample, GSSimpleTranExample_container1:GSSimpleTranExample] !
You might be using hash based load balancing (partitioned schema) while writing data into multiple spaces and not into a single node.
Please Use Jini Transaction manager with your operations.

The reason is that GigaSpaces attempted to route each of the two writes to  different partitions, which turned our local transaction into a distributed transaction.  Because we configured the application with a local transaction manager, the transaction fails.

To fix the application we need to specify a distributed transaction manager instead of a local one.  Here’s how:

Find the line in the Spring application context file, GSSimpleTranExample.xml, in which we specify a transaction manager:

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –><os-core:local-tx-manager id=“transactionManager” space=“gSSimpleTranExample”/>

and replace it with a line that looks like this:

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –>

<os-core:distributed-tx-manager id=“transactionManager” />

Note that the distributed transaction manager, unlike a local transaction manager, is not associated with a particular space.

Now run the client application.  This time it should work.  You can confirm the transactional behaviour using the techniques described in the earlier post.

This entry was posted on Monday, May 25th, 2009 at 8:39 am and is filed under Cloud, GigaSpaces. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.