Re: Concurrency question
Re: Concurrency question
- Subject: Re: Concurrency question
- From: Chuck Hill <email@hidden>
- Date: Wed, 1 Aug 2007 10:18:11 -0700
On Aug 1, 2007, at 5:00 AM, Miguel Arroz wrote:
Hi!
The contexts are locked. The problem is that it's not the same
context - it's a different context per thread, with local copies of
the same objects.
Synchronizing solves the sample problem, but as my real problem
is much more complex than this example, it starts to get a
little... ugly. Also, I still did not full understand why, the
objects in the thread that runs in second are not updated with the
data saved by the thread that run first. I suspect that the cause
of this is that the objects only receive the notifications to
update themselves after finishing the R-R. Can anyone confirm this?
Yes, if you are locking properly (and I know you are), the changes
only get merged at the end of the RR loop. You can do it yourself by
unlocking and relocking the EC.
About being solving 2 different problems or not, it depends on
the level os abstraction you use to look at it. :) From my point of
view, I'm solving one problem - the problem of concurrent updates.
My app has now enough info to solve the problem (OL fields, and how
to retry). It would work *if* the UPDATE WHERE data was fetched
from the original data in the context, and not in the row data.
It gets more complex than this. One quick fix is to have each EC in
its own EOF stack. But that can be rather memory expensive.
Chuck
On 2007/08/01, at 03:03, Ken Anderson wrote:
Miguel,
Is your editing context locked before calling incrementIt() ? I
would think that would solve your concurrency issue here.
If not, just synchronizing the method should solve the problem.
It may seem inelegant, but you really ARE solving 2 different
problems...
Ken
On Jul 31, 2007, at 7:41 PM, Miguel Arroz wrote:
Hi!
I'm trying to understand what's the best way to do something here.
Imagine that I need to get a object from the database, modify
some attribute based on itself and save it again.
So, we have the method:
public void incrementIt() {
if( aIsEven() ) { // 1
setB( b() + 1 ); // 2
}
setA( a() + 1 ); // 3
editingContext.saveChanges(); // 4
}
Well, it's easy to solve the problem of update conflicts
between two different instances of the app. Just tick the OL lock
for a and b fields, catch the evil expression, refault the
object, and recalculate (and retry to save). That's "easy".
Now, my problem is inside the same instance! Imagine that this
method runs at the same time and we have the following run order,
for threads X and Y, with the same object in two different
contexts (and imagine a = 3):
X 1
Y 1
X 3
X 4
Y 3
Y 4
This will produce wrong results, but it won't cause any locking
exception. Why?
1) Both threads get the object with a = 3.
2) Both threads do not run line 2 because 3 is not even.
3) The thread X increments a, and saves it. When saving, the
object at thread Y will have it's 'a' attribute updated, assuming
both objects are in the same coordinator.
4) The thread Y increments a again, and saves it. N optimistic
locking exception will be thrown, because the coordinator
snapshot was updated in the last commit, so the SELECT FOR UPDATE
will run OK.
This will cause a to be 5, but b did not increment as it
should. The problem is that, when saving, we are basing OL on the
row snapshot (that is updated during the process) and not to the
original value of the object when it was loaded into the editing
context.
Well, this may be solved using the "classic" Java "syncronized"
stuff, and locks and all that stuff. But this is a bit stupid. I
already solved the problem with OL for the, theoretically, more
difficult case of managing several app instances. Do I have to
solve it all over again, in a different way, to deal with
multiple updates on the same instance? Isn't there a way to use
OL just like I'm already doing?
Yours
Miguel Arroz
Miguel Arroz
http://www.terminalapp.net
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
Miguel Arroz
http://www.terminalapp.net
http://www.ipragma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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