• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Concurrency question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Concurrency question


  • Subject: Concurrency question
  • From: Miguel Arroz <email@hidden>
  • Date: Wed, 1 Aug 2007 00:41:10 +0100

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Concurrency question
      • From: Ken Anderson <email@hidden>
  • Prev by Date: [Reminder] The surveys
  • Next by Date: Re: takeValueFromRequest phase
  • Previous by thread: [Reminder] The surveys
  • Next by thread: Re: Concurrency question
  • Index(es):
    • Date
    • Thread