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> 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) > 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
