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.
Or ?
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
