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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
