Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Space Persistency Transaction Behavior on Exception

Hello! Recently I wrote a testharness for experimenting space persistency in synchronous mode. (Direct Persistency). I extended the SpaceSynchronizationEndpoint with my own database related APIs.(not using Hibernate) The test is as follows.

Step 1. Start a transaction via the distributed transaction manager Step 2. Write Type1SpaceClass to the space Step 3. Write Type2SpaceClass to the space Step 4. Commit the transaction.

I can see the Type1SpaceClass and Type2SpaceClass are picked up by SpaceSynchronizationEndpoint after calling transactionManager.commit(status). By that time, if there is an exception thrown out at the database level, the exception can be caught and re-throw from the SpaceSynchronizationEndpoint. In my test, I throw the following.

throw new SpaceSynchronizationEndpointException

Then from the Mahalo logs, it seems the original transaction is neither committed nor aborted.

If I throw an exception in between Step2 and Step3, I can clearly see the transaction is aborted. I'm wondering if there are exceptions thrown out from the SpaceSynchronizationEndpoint, why the mahalo transaction is kind of 'hanging'? How can I rollback/abort this transaction in a programmatic way?

When the exception is thrown out from the transaction, the mahalo logs the following.

[com.sun.jini.mahalo.transactions] - aborted transaction id 2

But if an exception is thrown out from the endpoint, the log below is shown.

[com.sun.jini.mahalo.transactions] - 1 participants joined

Thanks in advance!


asked 2014-07-31 02:33:36 -0500

conanzxn's avatar

updated 2014-08-01 08:23:58 -0500

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

You should avoid using this topology since you will have multiple primary space instances - each interacting with the same database instance - potentially locking the same object. You should use partitioned space to avoid conflicts. It will allow you also to scale the data grid and the application in a better way.

Any reason why you are using direct persistence? it will limit the data grid performance.


answered 2014-08-01 10:10:24 -0500

shay hassidim's avatar
edit flag offensive delete link more


I agree we will have multiple space instances. However, I want some space operations to be sync with the database but others not. The reason for that is currently the database operations are write behind. Once a Gigaspace transaction is finished, there might be problems while persisting to the DB so I want both Gigaspace transaction and the DB transaction to be rolled back. However, without direct persistency, those two type of transactions are rolled back separately so it leads to data inconsistency problems.

conanzxn's avatar conanzxn  ( 2014-08-01 10:21:06 -0500 )edit

btw, are you working for Gigaspaces? Our company is a Gigaspaces customer. Can I get an account to login to the customer zone? I sent a request a couple of days ago but no replies yet. Many thanks!

conanzxn's avatar conanzxn  ( 2014-08-01 10:25:45 -0500 )edit

Yes. I work for GigaSpaces. I've asked support to contact you.

shay hassidim's avatar shay hassidim  ( 2014-08-01 10:59:40 -0500 )edit

Thanks very much

conanzxn's avatar conanzxn  ( 2014-08-01 11:00:15 -0500 )edit

Hi, Can you please resend your request? we don't seem to find your original one. Many thanks,

inbarc's avatar inbarc  ( 2014-08-03 03:16:59 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2014-07-31 02:33:36 -0500

Seen: 226 times

Last updated: Aug 01 '14