James Dekker wrote:What happens if a transactional method with certain transaction attributes call a method at the same bean with different transaction attributes?
Actually, what you have here is a "code smell" basically there is something wrong with the design. So If I have one bean with two public methods a() and b() and both are Transactional. a() calls b(). That call to b will not go through the proxy, you are already in that bean instance. So it will not go out and recall it through the proxy, it calls it directly. So b() in a sense will be in the context of a()s transaction, because it is still in a sense in a().
once you are within the actual instance of the bean it will call other methods in that same instance directly.
So why is that a code smell. 2 possible reasons . 1) a() should not be a client to b(). Basically you are breaking interfaces and their purpose. a public interface is for clients outside of the class. or 2) b() should NOT BE in the public interface. a() is the only "client" of b() and therefore b() should have been declared private.
So the fix, move b() into another interface/another class so that a() can be a public client of b(), or make b() private.
I agree with Marks analysis I thought we were talking about nested transactions across services or layers.
The bit about not going through the proxy is specific to interface based proxying correct? I can't recall ever having tried it but I would think using CGLIB and AspectJ class based proxies would allow you to have a nested @Transactional private method in the same bean. I know the aspect j marker would be there and I just always assumed it would work. I know I have had private Transactional methods within services before on a few occasions but that is usually to keep the transaction open for the smallest amount of time needed on service calls which can take some time to complete , and in that case the service method exposed by the interface is not transactional.