Hazelcast and Spring Transaction

760 views
Skip to first unread message

Brijesh Kansagra

unread,
Jul 15, 2014, 9:13:06 AM7/15/14
to haze...@googlegroups.com
Hi,

Currently I am using Spring and Hazelcast in my application. I am manually sync both transaction. 

First Spring transaction is committed followed by hazelcast transaction.

I have hazelcast server running and client connects to it.

Spring and hazelcast transaction are opened at client side.

First data is committed to DB using spring transaction followed by map is updated by hazelcast transaction.

Is it possible to do transaction handling on server side ? Like just before saving data into hazelcast map the same data is committed to DB.

The purpose is to avoid maintaining spring and hazelcast transactions simultaneously for each operation.

Please let me know if you need more details.

Thanks,
Brijesh Kansagra


michael...@gmail.com

unread,
Jul 17, 2014, 8:42:41 AM7/17/14
to haze...@googlegroups.com
Brijesh,

I'm starting to look into linking Hazelcast transactions with Spring as well. I'll probably go with a best attempt, single phase commit approach just because it tends to be a lot easier to implement and debug. I'll let you know if I come up with anything.

In the mean time, you might want to read up on two-phase commits which Hazelcast supports (http://hazelcast.org/docs/3.0/manual/html-single/#TransactionInterface). With two phase commits you can link the commit of two different transactional entities like a database and Hazelcast. Spring provides support for it so it might just be a matter of adding your Hazelcast transaction to the Spring transaction manager.

-mike

Jaromir Hamala

unread,
Jul 17, 2014, 8:47:54 AM7/17/14
to haze...@googlegroups.com
Hi Brijesh,

what do you mean by "handling a transaction on server side"? Hazelcast server doesn't know your transaction boundaries, only client does. 
You could use Spring (on a client side) to control Hazelcast transaction, but it's not a straightforward thing to do. AFAIK you have 2 options:

1. You could implement own Hazelcast-aware Spring transaction manager by extending org.springframework.transaction.support.AbstractPlatformTransactionManager. 
2. If you are in Java EE environment you could deploy the Hazelcast Resource Adapter, configure XA resources and let Spring to use JTATransactionManager (=it delegates to a container)

Now both options have its own gotchas:
The 1st approach means you have to implement Spring transaction manager (not exactly a trivial code to write) then Spring would be able to control the Hazelcast transaction, but you would have to control DB transaction yourself. So it's not really an improvement from your current state

The 2nd approach seems better, but: 
1. you need a JTA transaction manager. It most cases it means Java EE container. 
2. XA protocol usually means a performance penalty. + various JDBC drivers have mixed level of XA-support.
3. it requires a non-trivial amount of configuration
4. Hazelcast Resource Adapter exposes just a subset of features

Some of these gothas could possibly be eliminated by piggy-backing on JTA synchronizations instead of using a full-blown XA protocol, but again, it's a non-trivial amount of work.
If course I don't know your requirements, but If I was in your shoes, I would pursue another design which wouldn't require a synchronization of transactions at two different resources. 

Cheers,
Jara

Mike Pilone

unread,
Jul 20, 2014, 9:38:37 PM7/20/14
to haze...@googlegroups.com
I just pushed my first attempt at a HazelcastTransactionManager and a TransactionAwareHazelcastInstanceProxyFactory. The former is a full Spring PlatformTransactionManager which manages the Hazelcast transaction at the top level. The latter will create a proxy for a HazelcastInstance and enroll a transaction synchronization in the main transaction to link a Hazelcast transaction to a JDBC transaction for example.

I'm not convinced that my API and level of integration is correct yet. Hazelcast makes it a bit complicated by exposing a separate TransactionContext used to create transactional objects. This is on top of the fact that transactional objects have a different API than their non-transactional counterparts and Hazelcast automatically pins the transaction to the thread.

Only IQueue is supported right now, but other data structures can be added easily. I'm going to keep thinking about the API and integration level but you're welcome to checkout the code in my develop branch here: https://github.com/mpilone/hazelcastmq/tree/develop/hazelcastmq-spring/src/main/java/org/mpilone/hazelcastmq/spring/tx

-mike

On Tuesday, July 15, 2014 9:13:06 AM UTC-4, Brijesh Kansagra wrote:
Message has been deleted
Message has been deleted

Brijesh Kansagra

unread,
Aug 19, 2014, 8:55:56 AM8/19/14
to haze...@googlegroups.com
Thanks Mike and Jaromir for your inputs..
Reply all
Reply to author
Forward
0 new messages