Re: [Springframework-developer] RE: Reworkings and new features

[Rod J. <rod...@in...>]

People are bound to want to do it. As I make clear in E 1:1 I think doing
smart stuff in views is pretty vile.

I vote we support it but warn against the dangers.

Regards,
Rod

----- Original Message -----=20
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, December 10, 2003 7:43 PM
Subject: RE: [Springframework-developer] RE: Reworkings and new features


Chris,

No doubt about that: I've been reluctant to add OpenSessionInView support=
 to
Spring for quite a while, as I don't want to offer to keep transactions o=
pen
during view rendering - or even worse, to dispense with transactions
altogether just to get lazy-loading in views.

But now, I consider our solution of keeping a non-transactional Session o=
pen
as appropriate for the case where you simply don't care about data loadin=
g
exceptions in the view: Such exceptions don't affect transactions anymore
but "just" cause a broken view page if additional data can't be loaded - =
and
that won't happen too often. Accepting that risk is a valid tradeoff for
view-driven lazy loading.

Personally, I prefer appropriate initialization of the model in the
controller too. The point is that we don't force users into a single choi=
ce
anymore: It's up to them now. I consider this an important new feature th=
at
turns Spring's Hibernate support into a viable option for Hibernate users
who prefer lazy-loading in views.

I believe that the tradeoff that our OpenSessionInView handling offers is=
 as
good as possible: After all, you can't have lazy loading in views without
the drawback of risking broken views in case of exceptions. Ad-hoc soluti=
ons
as typically seen with Hibernate, involving custom ThreadLocals and the
like, are arguably worse choices than our out-of-the-box solution.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Chris Nokleberg
Sent: Wednesday, December 10, 2003 8:18 PM
To: spr...@li...
Subject: [Springframework-developer] RE: Reworkings and new features


j=FCrgen h=F6ller [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 alw=
ays
> 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" bu=
t
in practice it can be difficult to make sure all of the lazy-loading
objects in your model have been initialized.

Chris




-------------------------------------------------------
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


-------------------------------------------------------
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=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer