HI Miguel,
You sure do know how to have fun with WO!
On Jul 31, 2007, at 4: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".
Correct. That _is_ the easy case.
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?
Because when one EC saves, the changes are merged into all the other
editing contexts (queued for later merging by other editing contexts).
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.
Correct.
Well, this may be solved using the "classic" Java "syncronized"
stuff, and locks and all that stuff. But this is a bit stupid.
Agreed.
I already solved the problem with OL for the, theoretically, more
difficult case of managing several app instances.
And in theory, theory is the same as practice.
Do I have to solve it all over again, in a different way, to deal
with multiple updates on the same instance?
Yes.
Isn't there a way to use OL just like I'm already doing?
No.
Is this on pages or in threads? Are the relevant editing contexts
getting locked and unlocked or staying locked during all this?
Chuck
--
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
