Transaction propagation across multiple layers

[sb248]

Hello,

In my application, we have multiple layers through which a transaction must propagate through.

Service Layer (starts the transaction) --> Manager Layer --> DAO

All the methods in the service layer are configured to be transactional declaratively. However, the methods in the Manager & DAO are not configured to be transactional.

In this case, will the transaction starting from the service layer propagate to the called method in the Manager & DAO layer ?? Or else will I have to make the methods in the Manager & DAO layer transactional explicitly ??

Service layer code:

public class LibraryServiceImpl implements LibraryService {
	
	private UserLibraryManager userLibraryManager;
	
    public void renameUserLibryNode(Integer nodeUid, String newName) throws LibException {
 		userLibraryManager.renameUserLibryNode(nodeUid, newName);	
    }

    public void setUserLibraryManager(UserLibraryManager userLibraryManager) {
        this.userLibraryManager = userLibraryManager;
    }
    
}

Manager Layer code:

public class UserLibraryManagerImpl implements UserLibraryManager {

	private UserLibraryDao userLibraryDao;
	
	public void renameUserLibryNode(Integer nodeUid, String newName) throws LibException {
		userLibraryDao.renameUserLibryNode(nodeUid, newName);
	}
	
	public void setUserLibraryDao(UserLibraryDao userLibraryDao) {
		this.userLibraryDao = userLibraryDao;
	}
	
}

DAO layer code:

public class UserLibraryDaoImpl implements UserLibraryDao {

public void renameUserLibryNode(Integer nodeUid, String newName) throws LibException {
// db update operation....might throw a checked exception.
}
}

<!-- this is the service object that is made transactional -->
  <bean id="libraryService" class="x.y.service.LibraryService "/>

  <!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean below) -->
  <tx:advice id="txAdvice" transaction-manager="txManager">
  <!-- the transactional semantics... -->
  <tx:attributes>
    <!-- all methods starting with 'get' are read-only -->
    <tx:method name="get*" read-only="true"/>
    <!-- other methods use the default transaction settings (see below) -->
    <tx:method name="*"/>
  </tx:attributes>
  </tx:advice>
  
  <!-- ensure that the above transactional advice runs for any execution
    of an operation defined by the LibraryService interface -->
  <aop:config>
  <aop:pointcut id="libraryServiceOperation" expression="execution(* x.y.service.LibraryService.*(..))"/>
  <aop:advisor advice-ref="txAdvice" pointcut-ref="libraryServiceOperation"/>
  </aop:config>

[chudak]

if it is started in the service layer, it will propagate through everything....

[rhiannonmartin]

If required, I presume is it ok to add @Trasactional to DAO layer methods also, eg if wanted to either change the Propogation behaviour, or to ensure that even if this DAO method is called by a non-transactional method, then it itself will start a new transaction and run in that (ie use REQUIRED) ?
If I am correct, this latter style seems to be done in the Spring Recipies book on page 269 for the purchase() method ?
Thanks very much

[sb248]

I tested out my code and it seems like I just need to make the service layer methods transactional and the transaction will propagate through any additional layers via calls made from a service layer method.

I guess one might want to introduce declarative transactional behavior for the other layers when different transactional behavior is required in that layer.

[chudak]

You should apply your transaction boundaries around 'units of work'. It is ill advised to just make every method in your dao and service transactional. It may well be the case that you invoke your services from within the UI layer and that multiple service calls need to be part of the same transaction. In that case, the unit of work is in the UI layer, not at the service layer.

[sb248]

Thanks for the info... what you say is correct. From which layer one wants to manage transaction depends upon the transaction strategy implemented for that application.