Aaron, thanks, this I hope I sort of understand.
Still, in the garbage-collected environment, any object, far as I can say, should (a) be automatically disposed when there's no explicit reference to it, regardless of whether it is cheap or big; (b) if there's some internal means to keep unreferenced objects alive forever, it should be explicitly documented (e.g., like EOObjectStoreCoordinator.defaultCoordinator()). What am I overlooking? And, much more important question: is the explicitly called dispose indeed the right and safe way to get rid of an OSC, wouldn't it cause some other problems elsewhere in the future? Thanks, OC > On 29. 6. 2020, at 4:17 PM, Aaron Rosenzweig <aa...@chatnbike.com> wrote: > > OSC is a cursor to the DB. They aren’t particularly cheap to acquire. As far > as I know, they live until you dispose of them. They don’t automatically > dispose. They are not cheap like an editingContext. One OSC can service a > plethora of editingContexts. Simple WOApps have two OSC for the life of the > WOApp: > > #1 made for the JDBCInfo, kind of dumb to keep around, Wonder has calls to > close this one. > > #2 stays around and used for any new editing context you make where you don’t > specifically give it a new OSC. > AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> > e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > > >> On Jun 29, 2020, at 10:12 AM, ocs--- via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> Hi there, >> >> it seems finally I succeeded to find the culprit of the problem described >> below. Far as my testing shows, it seems an ObjectStoreCoordinator is never >> garbage collected (presumed it has been used at least once for a fetch). >> Since the OSC opens a socket to the database, this leads to the problem with >> a number of open sockets for a process. Far as my testing shows, the only >> way to make it to do poof is to call dispose manually, which seems a bit at >> the unexpected side, at least for me. >> >> My current test code looks like this: >> >> === >> class MainPage extends OCSComponent { >> def test { >> def osc=new OCSOSC(),ec=new OCSEC(osc) >> println "created $osc and $ec" >> def >> obj=EOUtilities.objectWithPrimaryKeyValue(ec,'DBAuction',1000001) //[FETCH] >> println "got obj $obj and dying..." >> ec=nil >> osc.dispose() //[WHATTHE] >> osc=nil >> System.gc() >> nil >> } >> } >> class OCSOSC extends EOObjectStoreCoordinator { >> void finalize() { >> println "### $this about to die" >> } >> } >> @InheritConstructors class OCSEC extends ERXEC { >> void finalize() { >> println "### $this about to die" >> } >> } >> === >> >> If both the lines marked [FETCH] and [WHATTHE] above are commented out, >> i.e., if the OSC never fetches, both the osc and ec objects report >> finalizing without a need to dispose. >> >> Nevertheless, once the fetch happens as above, [WHATTHE] must be active too >> — otherwise only ec gets garbage collected; osc never ever does (and >> subsequently also never releases its DB socket). >> >> Well the explicit dispose seems to be the fix for my problem, so far it >> seems to work properly; but since I did not find any mention of calling >> dispose manually nor using a dispose registry in the documentation >> (otherwise than those two registries related to archivation and D2JClient), >> I wonder whether this is the proper approach, or whether I am doing >> something wrong and sooner or later I am in for an ugly surprise? Any >> insight here? >> >> Thanks a lot, >> OC >> >>> On 21. 5. 2020, at 1:13 PM, OCsite <o...@ocs.cz <mailto:o...@ocs.cz>> wrote: >>> >>> Hi there, >>> >>> bumped lately into another weird problem. We import some data into DB in >>> background tasks. Up to yesterday, it worked normally; today six import >>> tasks were launched, and each of them seemingly hang in its first DB >>> operation. Restart did help; alas, the site admins did not try to ask JVM >>> to detect deadlocks when they restarted the application. >>> >>> The background task looks like this: >>> >>> === >>> class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation { >>> def performAction { >>> _thread.priority=Thread.MIN_PRIORITY >>> try { >>> try { >>> editingContext=ERXEC.newEditingContext(objectStore=new >>> EOObjectStoreCoordinator()) >>> editingContext.lock() >>> lognow 1, "=== preparing CSV import in EC $editingContext >>> ===" >>> >>> formPrototype=ERXEOGlobalIDUtilities.fetchObjectWithGlobalID(editingContext,formPrototypeGID) >>> lognow 1, "=== local prototype $formPrototype ===" >>> ... ... >>> === >>> >>> Always the “preparing” log was the last thing those threads presented; none >>> of them ever reported “local prototype”. There's no other related log in >>> there. >>> >>> Meantime the application ran normally and the worker tasks communicated >>> with the database all right (with an occasional report that some select >>> took 70-odd ms from ERXAdaptorChannelDelegate, we have the threshold at >>> 50). We run with ERXObjectStoreCoordinatorPool.maxCoordinators=1. >>> >>> Any idea what could have gone wrong and how to find the culprit and prevent >>> the problem in future? I thought a new EC in a new OSC can't be blocked for >>> long, but self-evidently, I was wrong, they seemed to lock indefinitely >>> (application was restarted ten-odd hours after the first import hanged >>> after its “preparing” report, still no “local prototype”). >>> >>> Thanks 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 >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >> <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
