Transaction declarations

[pokeefb]

First let me say that I am pretty new to Java, incredibly new to Spring, and that my head is spinning. I am providing maintenance for a web-based application using Spring and Hibernate, and one of the database transactions is currently far too big. My goal is to separate the single mega-transaction into a number of smaller transactions.

My class definition is like this:

public class longProcess implements IProcess
{

public void doLongProcess()
{

this.clearPreviousResults();
for( int i=0; i<MAX; i++ )
{
this.doSmallerWork();
this.saveNewResults();
}

}

public void clearPreviousResults(){ ... }
public void doSmallerWork(){ ... }
public void saveNewResults(){ ... }

}

The current Spring context file contains the following:

<bean id="longProcessTarget" class="org...TransactionProxyFactoryBean">

<property name="transactionManager" ref="transactionManager"/>
<property name="target">
... details of the longProcess bean ...
</property>
<property name="transactionAttributes">
<props>
<prop key="doLongProcess">PROPAGATION_REQUIRED</prop>
</props>
</property>

</bean>

My understanding of this is that Spring will manage a transaction around the "doLongProcess" method. Is that correct?

Can I break the process into smaller transactions simply by changing the XML configuration to identify different transaction attributes? E.g.:

<property name="transactionAttributes">
<props>
<prop key="clearPreviousResults">PROPAGATION_REQUIRED</prop>
<prop key="saveNewResults">PROPAGATION_REQUIRED</prop>
</props>
</property>

[Andreas Senft]

Note that invocations on "this" will not again being proxied (unless you use AspectJ). So the answer to your question is: Normally it should not work this way.

However, you can have two beans. One bean with the "doLongProcess" method which is not declared to be transactional and which invokes the other methods on the other bean (which are transactional).

While this describes a technical solution you have to check to not violate assumptions on atomicity required by the domain logic. You have to ensure that a rollback in one of the smaller methods does not leave an inconsistent state.

Regards,
Andreas