On 2011-12-06, at 2:31 PM, Lachlan Deck wrote: > On 07/12/2011, at 9:23 AM, Philippe Rabier wrote: > >> I can feel how uncomfortable you are. >> >> What makes me confused is to never see this bug before. It's hard to believe >> that nobody saw the errors if there are error. But on another side, I (and >> all the team) worked on many applications so following the explanation, I >> don't know why we don't see this issue much more often. > > I suspect the more prevalent use of concurrent requests these days has > exposed this bug.
It is worth carefully reading over the reproduction steps: > * How it fails: A request is handled by WorkerThread0. By the end of > the request the eo has been modified but not saved, so the EOObserverCenter > remembers > * that WorkerThread0's most recent object is that eo. Fifteen more > requests are handled by WorkerThreads 1-15 in sequence. One of these requests > completes > * the modification of the eo and calls saveChanges on the ec. At > this point the ec tells the EOObserverCenter to forget about its most recent > object, but > * it's being set to null in WorkerThread14 or whatever, not > WorkerThread0. > * > * The next request will wrap around to to be handled by > WorkerThread0. This request modifies an attribute on the eo, but since the > EOObserverCenter still > * thinks WorkerThread0 has already noticed the eo, it ignores the > willChange and the ec doesn't grab a snapshot. > * > * Later in the processing of this request, a different object gets > changed, willChange gets called and the ec grabs a snapshot of the second > object. Then, > * a change gets made to the original eo, willChange gets called, and > since the EOObserverCenter was paying attention to the second object, it goes > ahead > * and notifies the ec about the first object. > * > * At this point the ec grabs a snapshot of the first object, but > it's too late -- the object has already been modified, the ec didn't know > about the > * previous change, so when saveChanges gets called the previous > changes don't get saved to the database. And now your object graph no longer > matches the > * database, and your app is borked. Note that it has to be the _same_ eo (same GID) and the same thread and it has to be in a modified but unsaved state. My guess is that unless your users are doing highly concurrent editing of the same data that this will rarely affect you. That is why I found it fixing Calven's problem so readily a surprise. >> And a question regarding the workaround: is there any drawback to call the >> EOObserver in the dispatchRequest method like suggested? > > For multiple active worker threads, a good question... > > Lachlan Deck > [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
