Sam wrote: > 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.
Thanks for the info. Just to nitpick, if you're accessing lazily loaded objects, you actually are starting a second transaction, just not explicitly. Your database driver must be in auto-commit mode if that works. This is explicit in the Hibernate reference manual (section 11.1.1), and also is mentioned on http://www.hibernate.org/43.html under "Can I commit the transaction before rendering the view?". My only point is that you'll get a second transaction if a service method is called OR if a not-yet-initialized collection or property is accessed in your view. If you're in auto-commit mode you may be more than just two, depending on how many lazy properties are fetched. > 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. Yes, that's what I'm hoping. I suppose I will find out soon. ;) Thanks... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
