On Jul 14, 2009, at 10:19 AM, Stamenkovic Florijan wrote:
Do you have simple code to reproduce? Can you share it?
No, I am seeing this in our complex proprietary app. However, it
should be extremely easy to mimic. Essentially, take your JC app,
run two client apps concurrently connecting to the same server,
simulate an update conflict, and there you go. So far there have
been no indications that this exception has anything to do with my
app specifically, so you should easily be able to recreate it.
Looping the list back in...
I am not able to reproduce this problem unless I push the EC to the
server without saving it to the database (RMI for example). Baring
that though I cannot reproduce the concurrency issue with either two
copies of the client on one machine or two separate machines. With
locking off on all the attributes I'm getting last-in-wins behavior as
expected.
Is this the scenario in your app, ECs being pushed to the server dirty
and uncommitted?
Even when I simulated that, I was able to catch the exception from
saveChanges in client2, revert that context, and client1 was able to
save as expected.
HTH,
John
_______________________________________________
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]
