Re: Dr. Miguel 'Optimistic Locking' Arroz [was Re: WebObjects stress Testing tool?]
Re: Dr. Miguel 'Optimistic Locking' Arroz [was Re: WebObjects stress Testing tool?]
- Subject: Re: Dr. Miguel 'Optimistic Locking' Arroz [was Re: WebObjects stress Testing tool?]
- From: Anjo Krank <email@hidden>
- Date: Thu, 3 Dec 2009 17:33:06 +0100
So your actual problem is that the EO doesn't save the old value in an
extra dict? Well, do so: create a (known key, optimization) dict with
the locking attributes and the values from __dictionary (after an
actual change, optimization).
Then use DBC delegate databaseContextWillOrderAdaptorOperations to
munge the values. Mind you, this is from a 5 min glance. But I think
it will work. Patches welcome...
Cheers, Anjo
Am 03.12.2009 um 16:45 schrieb Miguel Arroz:
Hi!
I still didn't have time to test that, sorry. :(
Anyway, I believe that won't solve the problem, because the issue
is not at the EC level, but below. Having the EC refusing merges is
good (I wrote a delegate for that), so I believe that should stay in
ERXEC, but it's only part of the problem. The biggest issue is the
snapshot handling in the OSC. The fact that there's only one
snapshot per object for all the ECs means that, when you save, the
OL check is being done against the status of the object left by the
last EC that saved it, and not the status that was the current one
when you read the object into the EC you are trying to save changes.
Sorry if this sounds a bit confusing, the post explains it better. :)
The thing is, OL is OK to avoid concurrent updates of the same data
by different instances. But there's really no good way to avoid
concurrent data updates in the same instance. You have no way to be
notified that you discarded the changes made by another thread in
the same instance. You could check, when saving, if there is any
merging notification waiting to be applied to the EC, but besides
being tricky, I'm not sure if you could do that 100% reliably in all
situations.
That's why I would like to have a snapshot per EC, so that I could
generate an SQL query that does OL checking against what I had when
I created that EC, and not against what was the last thing my
instance saved. It would take more memory, yes, but it would avoid
locking the OSC while applying changes to EOs.
Yours
Miguel Arroz
On 2009/12/03, at 15:29, Anjo Krank wrote:
I think this would be a terrible waste of mem? Also: didn't I add a
fix a week or so ago for you to look over? Wouldn't that help with
your problem?
Cheers, Anjo
Am 03.12.2009 um 16:26 schrieb Miguel Arroz:
I still believe snapshots should be linked to an EC and not an OSC
to avoid this problem, although that would require some heavy
changing to EOF.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden