Since by default WO uses a single ObjectStoreCoordinator/db connection, if you have concurrent request handling enabled, a long running query on one session can impact the time spent on other queries. If you want to see if this is your problem, you can log all your database activity everywhere with a few properties.
# ERExtensions # Transaction - Switching this to debug will start the sql ouputting. log4j.logger.er.transaction.adaptor.EOAdaptorDebugEnabled=INFO ## Enable delegate to emit SQL debugging info. The Logger used is ## log4j.category.er.extensions.ERXAdaptorChannelDelegate.sqlLogging er.extensions.ERXAdaptorChannelDelegate.enabled=true ## How long a statement must run to cause a log message. Messages with longer than ## error also emit a stack-trace er.extensions.ERXAdaptorChannelDelegate.trace.milliSeconds.debug=0 er.extensions.ERXAdaptorChannelDelegate.trace.milliSeconds.info=100 er.extensions.ERXAdaptorChannelDelegate.trace.milliSeconds.warn=2000 er.extensions.ERXAdaptorChannelDelegate.trace.milliSeconds.error=15000 ## MaxLength of the message er.extensions.ERXAdaptorChannelDelegate.trace.maxLength = 3000 ## What entities to watch er.extensions.ERXAdaptorChannelDelegate.trace.entityMatchPattern = .* ## Actually set the log level log4j.logger.er.extensions.ERXAdaptorChannelDelegate.sqlLogging=info ________________________________ From: OCsite via Webobjects-dev <webobjects-dev@lists.apple.com> Sent: Wednesday, January 31, 2024 1:27 AM To: OCsite via Webobjects-dev <webobjects-dev@lists.apple.com> Subject: loooong saveChanges prep-stage Hi guys, I've got logs from one of our installations with a pretty weird problem. We just happen to log immediately before ec.saveChanges() gets called; and we happen to have a DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations, which logs out soon as it is called. In this one log, the delay betw. those two logs — ie., the time saveChanges spends before the delegate method is called — repeatedly grows up to almost a minute (!) After some time the problem disappears and saving works normally; and then it occurs again. There's no other log around (most other threads wait on the OSC lock anyway), and with our app it so happens there's only one item in the adaptor op array to be inserted or updated. Once or twice there even has been nothing to save at all (ie., no changes in the EC when saveChanges was called), but even so, saveChanges took almost a minute before it returned. Can't be 100 % sure, but most probably, it was the very same problem; it is highly probable thus it does not depend on the enterprise objects being saved, but on something else. It never happened in any other installation of the same application, including my development one and our test one. Have you ever bumped into something like that? Any idea what might be the culprit and how to hunt the bug? Thanks a lot, OC ________________________________ Confidentiality Notice: This email, including all attachments and replies thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and are legally privileged. This information is confidential, and intended only for the use of the individuals or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this transmitted information is strictly prohibited. Please notify us if you have received this transmission in error. Thank you.
_______________________________________________ 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
