This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

As per the above code, transaction will be invoked for methods starting with save and delete in AppFacadeImpl.

Suppose, in AppFacadeImpl I have a dummy method create* which calls the save* method inside it. save* method executes few database operations.

If I try to invoke the create* method of AppFacadeImpl instead of save* method, I am getting an exception 'Session is closed' when i try to fetch a data from the database. Will declarative transaction won't start a transaction for sub methods?

Comment

I am not using AOP stuff in my code. Its simple declarative transaction management from the application context xml file. Any inputs would be of great help!

Declarative transaction management uses AOP proxies. The proxy intercepts the method calls to save* and delete*, and opens the transaction. The proxy only works if you call save* or delete* from outside the object, never if you make the call internally.

Comment

Declarative transaction management uses AOP proxies. The proxy intercepts the method calls to save* and delete*, and opens the transaction. The proxy only works if you call save* or delete* from outside the object, never if you make the call internally.

Declarative transaction management uses AOP proxies. The proxy intercepts the method calls to save* and delete*, and opens the transaction. The proxy only works if you call save* or delete* from outside the object, never if you make the call internally.

Comment

Actually, it is possible to wrap self-invocations with transactions. But I think it is only possible when using annotations. As the documentation states:

Note: In proxy mode (which is the default), only 'external' method calls coming in through the proxy will be intercepted. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with @Transactional!

Consider the use of AspectJ mode (see below) if you expect self-invocations to be wrapped with transactions as well. In this case, there won't be a proxy in the first place; instead, the target class will be 'weaved' (i.e. its byte code will be modified) in order to turn @Transactional into runtime behavior on any kind of method.

I am not sure if it is possible to mix declarative-based and annotation-based transaction management. If it is, and annotations overrides declarative-based, you could mix them to solve your problem.