I suppose Spring's transaction management would start a second transaction after rolling back the first one, but ONLY if you call a second service method that is wrapped in a transaction after getting an exception in a prior one. Generally, my code is written such that a listener will probably only call a single service method directly, and any others will be called from inside the first, so the transaction that surrounds the first method will be inherited by any methods that are called from within it. However, Spring's transaction manager will most definitely leave the session open after a transaction has been rolled back, which allows any lazily loaded objects to be loaded from the session during the rendering phase. I can't guarantee it isn't a problem, but we've never had any issues with it, so I suspect the warning against reusing a rolledback session is related to writing objects baxck to the db, not simply reading them. Regardless, if you always catch the exception and go to an error page, you'll never need to worry about lazily loading objects after the excpetion causes a rollback, and that's about 98% of our cases.
--sam On 6/20/07, Michael Sims <[EMAIL PROTECTED]> wrote:
Sam wrote: > In my case, I'm using Spring's transaction management code to inject, > via AOP, transaction semantics around service method calls. This > means that my transaction commits when the service method (called from > the listener, almost always) returns, so I can catch any exceptions > before I even start rendering a response. In the vast majority of > cases, if I get an error, I'm going to show an error page, so > accessing objects that may cause lazy loading after the exception and > rollback really isn't a problem, but I will say that in the few > instances where it does occur, it doesn't appear to be a problem, > precisely because anything involving lazy loading while rendering the > view is guaranteed to be a read-only operation. So, Spring's transaction management does in fact start a second transaction on the same session, even after an exception has been thrown, and you haven't seen an issue from this? I think I'm going to go this route too, and only worry about it if a problem comes up. If it does, I'll just make sure to eager fetch everything I might need on a listener method that might throw an "expected" exception, before the first transaction is committed, and then I'll just close the session rather that start a second transaction. > So in our case, we don't have to explicitly handle a transaction > manager, cause Spring is automatically injecting the start and commit > of each transaction, as appropriate, and that is all defined in a > config file rather than in code. That's very cool. At this point in time the explicit calls to manage the transactions aren't bothering me, although I will probably refactor them out in the future. I haven't gotten into AOP just yet and I'm not ready to introduce another complication, but it's definitely on my to-do list. Thanks... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
