hi mike what you are describing here relieves my heart! back in february (https://sourceforge.net/mailarchive/message.php?msg_id=ce7f98ec0702010654w560f4a8dxd6420d6dc39580f3%40mail.gmail.com) i tried to argue why i needed a seperate osc because i was having the "blow-away-other-changes-in-the-EO" effect but couldn't explain it so detailed as you did and didn't even think i would meet once a EOF bug ....
thanks a lot for that detailed description! oliver On 8/2/07, Mike Schrag <[EMAIL PROTECTED]> wrote: > My reply was too big with the attachments, so I moved my response > into the wiki: > > http://wiki.objectstyle.org/confluence/display/WO/ > Programming__WebObjects-EOF-Using+EOF-Problems > > The last one, "Strange Locking Problems" ... And for the lazy: > It would appear that there is, in our opinion, some bugs related to > optimistic locking within a single EOF stack. Essentially what it > boils down to is that it appears that the update database operation > that is created as a result of a call to .saveChanges() is backed by > the EODatabaseContext snapshot and NOT the "working" snapshot inside > in the EO in the editing context it came from. What this means is > that while changes are not merged until you .unlock() and .lock() > under normal circumstances, because the underlying snapshot that EOF > diffs your changes against on save is the DBC snapshot, it's > effectively inadvertently "merged" on commit. That is to say that if > another EC makes changes and saves, then you make different changes > and save, you will blow away their changes with no sign of an > optimistic locking exception because your snapshot IS their snapshot > now (meaning, it looks like just you are overwriting their changes, > versus the reality of the situation that you are actually conflicting > with their changes). After discussing this some, we believe that if > the update operation used a version of the EO's backing snapshot > instead that these weird behaviors would be fixed and it would behave > exactly like a normal conflicting update if you were in two EOF > stacks. The current behavior smells of bug, but I'm curious if anyone > a dissenting opinion on the topic. It's certainly really complicated > and nasty down in that code, so it's possible there's some crazy > justifiable reason for it. > > Go to the wiki for the diagrams. > > ms > > On Aug 2, 2007, at 1:12 AM, Chuck Hill wrote: > > > The problem comes in when the modifications are made and saved > > after your editing context has been locked in the RR loop. I > > tricked ;-) Mike into looking at this today with. Looks like > > tigers lurk here. Maybe Mike will comment. > > > > > > Chuck > > > > > > On Aug 1, 2007, at 2:34 PM, Pierre Bernard wrote: > > > >> You can simulate OL, by listening to merge notifications. If it > >> affects a modified object you can later on refuse to save. > >> > >> Pierre > >> > >> > >> On Aug 1, 2007, at 7:18 PM, Chuck Hill wrote: > >> > >>> > >>> 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 concurrencyssue her > >>>>> > >>>>> 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 (Webobjects-dev@lists.apple.com) > >>>>>> Help/Unsubscribe/Update your Subscription: > >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/kenlists% > >>>>>> 40anderhome.com > >>>>>> > >>>>>> This email sent to [EMAIL PROTECTED] > >>>>> > >>>> > >>>> 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 (Webobjects-dev@lists.apple.com) > >>>> Help/Unsubscribe/Update your Subscription: > >>>> http://lists.apple.com/mailman/options/webobjects-dev/chill% > >>>> 40global-village.net > >>>> > >>>> This email sent to [EMAIL PROTECTED] > >>>> > >>> > >>> -- > >>> > >>> 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/webobjects- > >>> lists%40houdah.com > >>> > >>> This email sent to [EMAIL PROTECTED] > >> > >> - - - > >> Houdah Software s. à r. l. > >> http://www.houdah.com > >> > >> HoudahGeo: One-stop photo geocoding > >> HoudahSpot: Powerful Spotlight frontend > >> > >> > >> > >> > > > > -- > > > > 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/mschrag% > > 40mdimension.com > > > > This email sent to [EMAIL PROTECTED] > > > _______________________________________________ > 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/oliver.egger%40gmail.com > > This email sent to [EMAIL PROTECTED] > _______________________________________________ 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]
