RE: [Springframework-developer] Pre-binding validation

[Daniel M. <mi...@pa...>]

Juergen,

In my case, I am not using an HttpSession form
(AbstractFormController.sessionForm=false). I am using the Open Session in
View pattern. I have read on the lists that this is a dangerous pattern to
use because DataAccessExceptions could "break" the session object. As an
aside can you refute or verify this formally? Could the session somehow be
discarded and reloaded after a DataAccessException to fix this pattern?.
Here is my use case:

Initial GET request
	load object from db
	showNewForm -> display object values in formView

Form submission
	load object from db
	bind form values to object
	validate
	if error return to formView
	else show successView

I am trying to conserve memory by making minimal use of the HttpSession.
Maybe this is not such a big deal, I'd be very happy to hear your opinion. I
am also trying to combat the problem of an initial GET request followed by
no form submission (user follows some other link on the page with no
intention of returning to the form), which abandons the form object in the
session. This last issue seems like a real problem to me because the session
is bloated with a useless form object for the remaining duration of its
existence.

Thanks for taking time to consider the issue. I thought this thread had died
:)

Daniel Miller

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jürgen höller [werk3AT]
Sent: Wednesday, May 19, 2004 7:11 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Pre-binding validation


Daniel,

The problem that you indicate occurs when you bind request parameters to a
*freshly loaded* Hibernate object in combination with the Open Session in
View pattern. However, that sort of binding is not the typical case; do you
have a concrete use case for it?

Typically, you will load a Hibernate object for displaying a form first. On
submission (in a separate request), the object will be taken from the
HttpSession and populated with request parameters. In that case, the
Hibernate object is not registered with an active Hibernate Session anymore,
therefore changes to it won't get persisted. Only after successful
submission of the form, you will explicitly reassociate such an object with
a Hibernate Session - and only then the changes will get persisted.

So for the typical form case, the Open Session in View pattern should not
cause such side effects. And of course, if you don't use the Open Session in
View pattern in the first place, you'll *never* have such side effects.

If I missed your point, please tell me :-)

Juergen


________________________________

Von: spr...@li... im Auftrag von
Daniel Miller
Gesendet: Mi 12.05.2004 04:39
An: Springframework-Developer@Lists. Sourceforge. Net
Betreff: [Springframework-developer] Pre-binding validation



Recently while browsing the Help list (man do I still have a life or not?) I
came across this post:

https://sourceforge.net/forum/message.php?msg_id=2564738

It got me thinking about a potential problem with Spring MVC. Spring MVC
allows the user to bind the submit request directly to a persistent object
(assume that the command object has been loaded using a Hibernate DAO in
formBackingObject()). This eliminates a lot of code needed to transfer data
from the form (i.e. Struts ActionForm) to the persistent object. However
there is a potential problem here:

All data that does not trigger binding failure is bound directly to the
persistent object _before_ validation.

If I understand the thread local session pattern correctly, any
transactional method call that performs a flush after this point will cause
Hibernate to collect all of the persistent objects that it knows about (all
objects in the current session) and update the database with the contained
values.

<quote reference="hibernate_reference.pdf" chapter="8.4">

Persistent instances (ie. objects loaded, saved, created or queried by the
Session) may be manipulated by the application and any changes to persistent
state will be persisted when the Session is flushed (see "flushing" below).
So the most straightforward way to update the state of an object is to
load() it, and then manipulate it directly.

</quote>

and the relevant section on flushing:

<quote reference="hibernate_reference.pdf" chapter="8.9">

>From time to time the Session will execute the SQL statements needed to
synchronize the JDBC connection's state with the state of objects held in
memory. This process, flush, occurs by default at the following points
* from some invocations of find() or iterate()
* from net.sf.hibernate.Transaction.commit()
* from Session.flush()

</quote>

Very sneaky, we don't even need to call update(persistent_object) to get our
object persisted.

At this point, Spring invokes a validator with the persistent object as its
subject. If there are errors, the user will be forwarded back to the form.
However, the database could be in an inconsistent state because any value
that was successfully bound to the persistent object could possibly already
have been persisted to the database due to some unrelated transactional
method call.

Please point out my error(s) here if I have made one or many.

One potential solution (inspired by above mentioned post):
Create a RequestWrapper that can be validated just like the persistent
object to which the request will be bound (I realize this could be messy
because it is essentially reverse reflection aka emulation). Then invoke the
validator substituting the wrapped request for the actual object _before_
binding.

Feedback is greatly appreciated.
Thanks.

Daniel Miller



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer