Spring Transaction propagation issue?

Theoretically it is possible, but not within the standard means of Spring's Transaction aspects. You would need to create your own aspect that duplicates the spring standard functionality, extending it for your special case. Perhaps it will even be possible to extend the original aspect they use.

Theoretically it is possible, but not within the standard means of Spring's Transaction aspects. You would need to create your own aspect that duplicates the spring standard functionality, extending it for your special case. Perhaps it will even be possible to extend the original aspect they use.(Probably you will have to define a custom annotation though, because you can neither override the @Transactional attribute nor extend the Propagation enum.) Here are some pointers: Spring Transaction Management, especially: Transaction propagation Using @Transactional Using @Transactional with AspectJ Also, you should consider reading the book AspectJ in Action, even if you just want to use Spring AOP, as it gives a very good overview.

A good starting point is to download the sources of the spring-aspects jar, see what they are doing there and provide your own extension of either org.springframework.transaction.aspectj. AbstractTransactionAspect or org.springframework.transaction.aspectj. AnnotationTransactionAspect To sum it up: I'm sure it can be done, but it will take a lot of work.

The Spring Transaction API is pretty good as it is though. Maybe you should learn to live with it's limitations. If not: start hacking (see above).

So you are saying that there is no spring out-of-the-box solution for it. I'll still try to look for more generic solution htat requires less work, before mark this answer as the best one. – Spiderman Aug 26 '10 at 9:41 sure, there is no need to choose the correct answer within one hour of the question.

But an upvote would be nice :-) – Sean Patrick Floyd Aug 26 '10 at 9:51 To close this case, I think that no workaround fit my requests. Therefore this behavior by design of Spring seems like a limitation to me. The only real solution is to override Spring's implmentation as suggested here.

– Spiderman Sep 13 '10 at 8:44 yes, but that's a perfectly acceptible suggestion from spring's point of view. That's why there is an AbstractTransactionAspect for you to extend. – Sean Patrick Floyd Sep 13 '10 at 9:09.

It looks like Propagation. NESTED is something that can help you: If B fails, the transaction started with A (and continued with B) will correctly rolledback to savepoint before B is called without touching A. When B is committed, only savepoint is released, nothing else is issued to DB.

Bascailly that means that changes made by B are "merged" into transaction A. After B finishes, in any above mentioned case A can decide weather to continue and commit (that will be a real commit to DB which will include all changes by A and B if it committed) or to rollback (that will rollback the transaction up to the state when it was created invalidating all changes by A + B).

Propagation. NESTED will not help me. Because if B will be finished normally and then afterwords the last part of A will throw an exception it will not roll back B as well, even though this is my intention.

– Spiderman Feb 27 at 11:38 @Spiderman: No, it will. I have updated my reply with more detailed description of the scenario. Try it :) – dma_k Mar 19 at 21:50.

Transactional( propagation = Propagation. REQUIRED, noRollbackFor = RuntimeException. Class).

Not good because in case B will be called NOT from A but from somewhere else outside, I want the call to B method to be wrapped with a transaction and that in case of runtimeException it WILL do roll-back. – Spiderman Aug 27 '10 at 19:51 @Spiderman: Why not to use two entry points for your logic: first one to be called from bean A (@Transactional(propagation = ..., noRollbackFor = ...) void myMethodSafe()) and second one to be called from any other place (@Transactional(propagation = ...) void myMethod()). Yes, two methods in interface, why not?

Alternatively you can have one interface method and additional flag boolean noRollbackForException, which is set to true when method is invoked from bean A and then it try / catch the necessary exception (when it set to false the exception is thrown further). – dma_k Feb 22 at 9:53.

One solution is to provide TWO bean definitions in your context.xml. One with PROPAGATION_REQUIRED which you will use when you want the bean to be transactional itself The second with PROPAGATION_SUPPORTS which you will use when you call the bean from inside an existing transaction (Actually, it could even be nontransactional). If you want to minimise duplication, you can factor common configuration into a parent bean definition.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.