Single transaction, multiple requests using DataSourceTransactionManager subclass

[dan@danieljshaw.com]

I'm hoping to discover if I am using the DataSourceTransactionManager in the proper way, as a base class to support long transactions that exist in our legacy system. Please don't tell me not to support long transactions across multiple requests, as this is not an option.
This class also must support a time out mechanism; we have a subscriber that relies on a timeout implemented in our current architecture.

My approach so far was to create a new Interface called SuspendablePlatformTransactionManager. (Perhaps this is not be the correct metaphor, since the original concept of transaction suspension, is to start a new transaction within the same workflow, and then resume the suspended transaction later down the line).
The interface extends PlatformTransactionManager and has two additional methods

package com.choicehotels.cis.infrastructure;

import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.DefaultTransactionStatus;

public interface SuspendablePlatformTransactionManager extends PlatformTransactionManager
{
   
   public DefaultTransactionStatus suspendTransaction(DefaultTransactionStatus status);
   
   public DefaultTransactionStatus resumeTransaction(DefaultTransactionStatus status);

}

This gives the hooks available to the caller (a Servlet in the simplest case) to suspend, and later resume, in another thread, the transaction.

I then created an extension to the DataSourceTransactionManager that also implements the interface.
This class overrides doCommit, doRollback, doResume, doSuspend, and newTransactionStatus.

At first I misunderstood the suspension process, and thought the suspend would occur on the currently running transaction, but this is not the case.
It is the new transaction that has not "begun" yet that is the target in the doSuspend call.

This led to a problem, in my code that would cause an NPE upon resumption of the existing transaction, since I was suspending the existing transaction object (which removes the connection holder from the transaction object)

My workaround is to reattach the connection holder to the "suspended" transaction upon resumption, but I'm really hoping there is a better and more elegant way.

Attached is the relevant code if anyone is interested in offering suggestions or alternatives.

Thanks in advance
Dan Shaw

[karldmoore]

I think this thread talked about a poor man's distributed transaction, which might be similar to what you're talking about.
http://forum.springframework.org/showthread.php?t=34880

[dan@danieljshaw.com]

Actually, the concept is not a bad idea, and might work for me..I'll definitely investigate more..

The difference here, is that the "client" in our case are mostly web pages, or REST like services we provide, and the transaction begins and ends on our server.. any transactions occuring on the client, have nothing to do with our services.

[karldmoore]

Actually, the concept is not a bad idea, and might work for me..I'll definitely investigate more..

I'm not suggesting it is a bad idea. The thread I posted described it as a poor mans distributed transaction as it could have been replaced with a stateless session bean.