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 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. There's almost certainly a way to use the classes provided by spring to do that work from within hiveming without actually using the spring aplpication context itself, if you don't want to eal with yet another IoC container\, and the mechanism works really well, allowing your application code to be completely independent of transaction semantics. To the listener method that makes the service call, it just looks like an exception was thrown in the service call if the transaction commit fails, and you can handle that case from within the listener pretty trivially. --sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
