Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-12-10 19:09:40
|
Colin, I'm not sure if I understand the issue. If view code simply doesn't = catch any exceptions but always lets them through, the OpenSessionInView = handler will be able to properly close the Session in any case. It would = just be dangerous if the view code tried to handle exceptions itself, or = called down to code that tried to handle data access exceptions - a = proper web MVC view should *never* do such things. Essentially, this isn't different from normal business and data access = code based on Spring: Fatal runtime exceptions like DataAccessException = or TransactionExceptions should not be handled by application code but = always be propagated to the surrounding transaction or data access = template. I don't see why views are different in that respect, but maybe = I just don't get the point... Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Tuesday, December 09, 2003 3:23 PM To: spr...@li... Subject: Re: [Springframework-developer] Reworkings and new features While I know people are always asking for the Open Session in View=20 pattern support, I personally think it is a pretty dangerous pattern to=20 use. As per the Hibernate docs, =20 http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#m= anipulating-data-s13-4 if Session throws an exception, the Session should be closed and=20 discarded, as it will be inconsistent. The Open Session in View pattern=20 will work ok if the view code ensures that once a Hibernate exception is = handled no more db related code is used, but since the session handling=20 is above all the other code, it does not enforce this in any way. In=20 fact, if the view code is calling down to some service code that does=20 the db access itself, the view code may not even know that db access is=20 being done. At a minimum, I recommend we annotate the Javadocs for these classes=20 with a warning about this aspect... Regards, Colin ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for = IBM's Free Linux Tutorials. Learn everything from the bash shell to sys = admin. Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Chris N. <ch...@si...> - 2003-12-10 19:17:58
|
jürgen höller [werk3AT] wrote: > Essentially, this isn't different from normal business and data access > code based on Spring: Fatal runtime exceptions like DataAccessException or > TransactionExceptions should not be handled by application code but always > be propagated to the surrounding transaction or data access template. I > don't see why views are different in that respect, but maybe I just don't > get the point... It can lead to broken pages if the exception occurs after the view writes enough to cause a flush of the underlying response buffer. Either you get half a page with an appended stack trace or you have to do some tricks to close all open tags and write out a meta tag to redirect. For these reasons I agree it is better to avoid "open session in view" but in practice it can be difficult to make sure all of the lazy-loading objects in your model have been initialized. Chris |
|
From: Colin S. <col...@ex...> - 2003-12-10 20:04:21
|
The big problem is related to which layers handle what. You say that the view code should simply not catch any exception but let them through, and that's it's inappropriate for the view layer to call down to code that handles data access exception. I disagree. If the view code is calling down to use-case driven service code which is doing its own transactions, etc., it may often be entirely appropriate that the service code catch and handle SQLExceptions/DataAccessException, and rethrow it as something else, perhaps a checked exception which the view layer may try to recover from and do something else. The point is, the view code doesn't even know that persistence (Hibernate) code is involved; a layer even above it is what's handling the Hibernate session, which will be destroyed by an action in a layer down below the view code. As far as the view code is concerned, it may be totally reasonable to then call another service (which may or may not do db access) at that point, and it would be trying to do it with a munged Hibernate session. Now the fact that using this pattern doesn't bit people in the ass more often is probably due to a number of factors. First of all, my gut feel is that some of the time when Hibernate throws an Exception that session is still perfectly fine after that (ie it is not necessarilly inconsistent). Secondly, many apps are probably pretty simplistic, and do let errors percolate all the way up, that is, the view code would never try call down to more service code doing db work after an error made its way up. But this is just luck to some extent, and using the pattern encourages a potential future problem... jürgen höller [werk3AT] wrote: >Colin, > >I'm not sure if I understand the issue. If view code simply doesn't catch any exceptions but always lets them through, the OpenSessionInView handler will be able to properly close the Session in any case. It would just be dangerous if the view code tried to handle exceptions itself, or called down to code that tried to handle data access exceptions - a proper web MVC view should *never* do such things. > >Essentially, this isn't different from normal business and data access code based on Spring: Fatal runtime exceptions like DataAccessException or TransactionExceptions should not be handled by application code but always be propagated to the surrounding transaction or data access template. I don't see why views are different in that respect, but maybe I just don't get the point... > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Tuesday, December 09, 2003 3:23 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Reworkings and new features > > >While I know people are always asking for the Open Session in View >pattern support, I personally think it is a pretty dangerous pattern to >use. As per the Hibernate docs, > >http://www.hibernate.org/hib_docs/reference/html/manipulating-data.html#manipulating-data-s13-4 >if Session throws an exception, the Session should be closed and >discarded, as it will be inconsistent. The Open Session in View pattern >will work ok if the view code ensures that once a Hibernate exception is >handled no more db related code is used, but since the session handling >is above all the other code, it does not enforce this in any way. In >fact, if the view code is calling down to some service code that does >the db access itself, the view code may not even know that db access is >being done. > >At a minimum, I recommend we annotate the Javadocs for these classes >with a warning about this aspect... > >Regards, >Colin > > |
