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