I see. Of course since the second window was originally loaded with
old data, when I hit save all the old data gets saved over the changes
made during the first window's save. Really not a big deal I guess
since my example is pretty contrived. If I ever did want to guard
against this though, is the usual way to manually lock the EC before
returning the form page and then manually unlock it after processing
the user's response? Or could you do something like check for changes
made by the user against a local snapshot of the data you save before
sending the Form page, and only update the EC with changes the user
actually made, instead of just updating the EC with all the data in
the form whether the user changed it or not?
Thanks,
Jeff
On Jan 10, 2009, at 8:13 AM, Mike Schrag wrote:
What could be causing this?
No, the two ec's in your example will properly update (you're not
holding an ec lock across requests, so the first EC is causing the
second EC to update). The easiest way to force an optimistic lock
is to go into your edit form on an EO, and then update the database
manually with SQL commands in the background. This will cause your
snapshot cache to be out of sync. The only way to get it to happen
INSIDE your app would be to have two EC's attempt to change the
value while both are locked.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jeffandmonica%40mac.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
