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: Kieran Kelleher <email@hidden>
- Date: Thu, 3 Dec 2009 15:53:09 -0500
1) Yes, there is a ERXJDBCConnectionBroker that does what you say. I
have not used it though.
2) Creating another OSC is not much overhead (IMHO) itself ...... it
is all the EO's and snapshots that are the overhead. I create new OSCs
for most background tasks. The one thing is that I dispose() on it at
the end of the task .... and the dispose() is only useful if you use
ERXJDBCAdaptor is used since the regular WO 5.3 jdbc adaptor opens two
connections for every OSC and leaves the stupid things open forever.
ERXJDBCAdaptor only opens one db connection and releases it when u
call dispose() IIRC.
3) If you use OSC synchronization (ERXOSCSynchronizer and
ERJGroupsSync) you will still haev the problem of snapshots changing
underneath you if you don't lock the OSC. So IMHO, the
OptimisticLockAction approach works well ..... and if the approach
"ain't broke, why fix it" :-)
On Dec 3, 2009, at 3:44 PM, Miguel Arroz wrote:
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
_______________________________________________
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