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]
