|
From: Daniel M. <mi...@pa...> - 2004-05-14 21:33:12
|
Oliver, This is a good idea. The object could even be evicted right after it is loaded from the db. Then changes wouldn't persisted, even if the validation logic were to perform an operation that involves a flush. When it is determined that the submission is valid, saveOrUpdate will put it back into the session and commit the changes. I decided that my initial suggestion was not a very good one after thinking about the potential complexity. Thanks for the feedback. Daniel -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Oliver Hutchison Sent: Tuesday, May 11, 2004 11:42 PM To: spr...@li... Subject: RE: [Springframework-developer] Pre-binding validation In the event of validation failure couldn't you just rollback the current transaction and start a new one for the rest of the request? Or, even simpler, use Session.evict to make sure that it will never get flushed. > -----Original Message----- > From: Daniel Miller [mailto:mi...@pa...] > Sent: Wednesday, 12 May 2004 1:19 PM > To: spr...@li... > Subject: RE: [Springframework-developer] Pre-binding validation > > > Hi Seth, > > > 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. > > >Great thinking, Daniel. I've always used a Command/FormBean because > often the web workflow doesn't match up to the domain objects > close enough. But you're right, I wouldn't want any flush() > to happen until after validation. > > >For this scenario to happen, a call to find() or iterate() > would have > >to > be called /on the session for this request/, correct? > Assuming a usual setup of one session for the request, and > the request itself is not multithreaded, how would this > condition arise? > > After validation failure: processFormSubmission() -> showForm() -> > referenceData() which could load objects from the database > using a find() or iterate(). > > Thanks for the quick feedback. > Daniel > > ------------------------------------------------------- > 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 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 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=dnemail3 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |