Check your "willUpdate()" logic and similar things such as "didUpdate()". It may be doing lots of calculations in certain situations that is almost but not quite an infinite loop.
On Wed, Jan 31, 2024 at 5:59 AM OCsite via Webobjects-dev < webobjects-dev@lists.apple.com> wrote: > Thanks, guys! > > I am pretty sure though the problem can't be a background process either > reading for a long time or saving for a long time, for I do use the > *ERXAdaptorChannelDelegate.trace* logs and through > *DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations* I > log each save — and there's nothing like that in the log in the vicinity of > those long *saveChanges*, alas. Thus the culprit must be something else. > > Perhaps indeed *something* locks the OSC pretty often and for a long > time, but that something is neither a long *SELECT* which would log > through *ERXAdaptorChannelDelegate.trace*, nor another unrelated save, > which would log through > *DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations*. > > Besides, it does not really feel like OSC locks caused by another thread. > Meantime, I've rigged an awk script to compute how long each *saveChanges* > takes, > and it looks like this: > - for a long time, all is OK > - when the save times begin to grow, they keep consistently long (e.g., > about 30 s each, or about 50 s each) for each save for awhile (a quarter or > half an hour), before things get back to normal > > If another thread locked OSC, it would most probably mean some > *saveChanges* would be long, but some quick; it does not seem probable a > background thread would *consistently* keep OSC locked so that *each* > *saveChanges* takes roughly the same (long) time. > > This rather feels by something at the beginning of *saveChanges* becomes > slow. This would most probably happen under the OSC lock, and given the way > it works, does not seem really plausible that it is simply waiting to > acquire the lock itself. > > For the moment, I'm rather outta ideas :( > > Thanks again and all the best, > OC > _______________________________________________ > 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: > > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > > This email sent to aa...@chatnbike.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
