Werner, many thanks for your answer.
Regards, Richard ----- Original Message ----- From: "Werner Guttmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 11, 2004 8:54 PM Subject: Re: [castor-dev] Castor in a Web Application? > > On Thu, 11 Mar 2004 16:38:16 +0100, Richard Grill wrote: > > > > >Hello, > > > >> Now, the difficult part now is d), as you might have to go back to the > >user with the 'fresh' data from the database, > >> and ask him to confirm his action again. > > > >... this could be very difficult situation from the user's point of view... > > > >Please imagine following situation: User's finished web formular editing - > >let's say after 15 minutes from opening the web formular. Then he clicks to > >Submit button and unfortunatelly get a message: ... "Sorry your data was > >modified in the database meanwhile - try to fill the formular again please > >..." > >Concerning some category of "serious" Web application this scenario is > >unacceptable for the users. > > > >It seems pessimistic locking is the only way how to avoid such situations. > > It'd be one way to address this, ... > > >Or ? > > .. but good form design (in this case) could and should remember all the values filled in by the user .. and assist him in a meaningful way to address the > fact that the underlying data has been modified. The hard bit here is to sync the form with two sets of data .. the one entered by the user, and the > changed data in the system (which the user used to fill the form in the first case). > > My 0.02 cents ... > Werner > > > > >Regards, > > > >Richard > > > > > >----- Original Message ----- > >From: "Werner Guttmann" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Sunday, December 28, 2003 1:11 PM > >Subject: Re: [castor-dev] Castor in a Web Application? > > > > > >> On Sun, 28 Dec 2003 10:25:53 +0100, Andreas Schildbach wrote: > >> > >> >Bruce Snyder wrote: > >> > > >> >> I'm not following your example completely so let me pose a simple > >scenario > >> >> for demonstration purposes: > >> >> > >> >> 1) Tx1 reads an instance of ObjectA from persistence > >> >> 2) Tx2 reads an instance of ObjectA from persistence > >> >> 3) Tx1 changes a value in the ObjectA instance and persists it. > >This > >> >> means that tx2 now is out of sync. > >> >> 4) Tx2 changes a value in the ObjectA instance and attempts to > >> >> persist it but receives a ConcurrentModificationException. This > >> >> is correct behavior > >> >> > >> >> Castor does not provide a method of synchronizing the object > >> >> instances. This is left up to the application because there is no easy, > >> >> universally acceptable method of achieving this type of behavior. > >> > > >> >Let's replace step 4 for a moment: > >> > > >> >4) Tx2 uses values from ObjectA for displaying in a web page. > >> > > >> >This step can occur repeatedly, and can also occur before step 3. > >> > > >> >What is the best/easiest way to always get the actual values with step > >> >4, without loading the instance from the database on each invocation > >> >(e.g. by using db.load() again)? > >> > >> There's no easy answer, but if I had to come up with an answer, this is > >what it'd be. Just don't. As Bruce has said, > >> there's no way to be informed about updates that have been made in other > >transaction(s). Just keep your copy in a > >> 'safe place' (e.g. store it to the HttpSession as an attribute), and make > >up your mind whether you need to persist any > >> changes later on. Now, if that's the case, that's exactly where Castor > >will indicate to you that you cannot easily store > >> changes to your data as the underlying data has been changed already. If > >Castor didn't warn you, you'd simply wipe > >> out somebody' else's changes by saving your data ... which would violate > >normal ACIDity. > >> > >> In other words, the recipe should read (for each thread): > >> > >> a) read your data > >> b) do something with it (even if you are just storing it). > >> c) try to persist any changes. > >> d) deal with any (ConcurrentModification)Exception that is a result of > >Castor/the database trying to get transaction > >> synchronisation right. > >> > >> Now, the difficult part now is d), as you might have to go back to the > >user with the 'fresh' data from the database, > >> and ask him to confirm his action again. > >> > >> I hope this helps. > >> Werner > >> > > >> >Regards, > >> > > >> >Andreas > >> > > >> >----------------------------------------------------------- > >> >If you wish to unsubscribe from this mailing, send mail to > >> >[EMAIL PROTECTED] with a subject of: > >> > unsubscribe castor-dev > >> > > >> > >> ----------------------------------------------------------- > >> If you wish to unsubscribe from this mailing, send mail to > >> [EMAIL PROTECTED] with a subject of: > >> unsubscribe castor-dev > >> > > > >----------------------------------------------------------- > >If you wish to unsubscribe from this mailing, send mail to > >[EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > > __________ Informacia od NOD32 1.662 (20040311) __________ > > Tato sprava bola preverena antivirusovym systemom NOD32. > http://www.eset.sk > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
