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: Miguel Arroz <email@hidden>
- Date: Thu, 3 Dec 2009 20:44:02 +0000
Hi!
I don't know EOF at that level well enough, although that might
work. However, it's a little dirty... :) I would prefer something a
little more integrated in the EOF architecture (that might have to
evolve a little). Maybe separating the OSC from the DB connections, so
that several OSCs could share the same connection. One would create an
OSC for the critical part, without having the extra load of creating
the connection itself. The OSC would be short lived, and as it would
be used only by the critical section, the snapshots wouldn't be
changed by anyone else, and it had the advantage of not locking up the
app to everyone else.
Now is the time you say "ER<something> does that"!
Yours
Miguel Arroz
On 2009/12/03, at 16:33, Anjo Krank wrote:
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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