Samuel, > On 17. 8. 2024, at 15:59, Samuel Pelletier <sam...@samkar.com> wrote: > If you create a new OSC, you will have no snapshot cache (I may be wrong on > this), so it is the expected behaviour.
I might be missing something, but I understand each OSC has its own set of snapshots. Independent on other OSCs, of course, but should work normally inside an OSC. Was I wrong? > I never create new OSC in my apps, why are you creating OSC like this ? To create an independent DB channnel, so that my fetches in this OSC do not need to wait for (potentially long) fetches in other OSCs. > If your fetches are long, check your database indexes. They are fast, the problem is that they happen at all. I log EC, OSC, and SQL, and it looks like this (they run in the same thread just by a chance; each time, it's a new R/R loop, they get assigned the same thread just since I do nothing else in the app at the moment): === 18 12:58:34.815|WorkerThread2/TEMPLOG created ec EC:5e8666eb/OSC:69463522 12:58:34.816 DEBUG "DBAuction"@453059304 expression took 1 ms: SELECT ... FROM "T_AUCTION" t0 WHERE t0."C_UID" = 1000147 //log:er.extensions.ERXAdaptorChannelDelegate.sqlLogging [WorkerThread2] 18 12:58:35.852|WorkerThread2 /TEMPLOG created ec EC:267a80b0/OSC:69463522 12:58:35.853 DEBUG "DBAuction"@453059304 expression took 1 ms: SELECT ... FROM "T_AUCTION" t0 WHERE t0."C_UID" = 1000147 //log:er.extensions.ERXAdaptorChannelDelegate.sqlLogging [WorkerThread2] 18 12:58:36.863|WorkerThread2 /TEMPLOG created ec EC:7bcddf5b/OSC:69463522 12:58:36.880 DEBUG "DBAuction"@453059304 expression took 1 ms: SELECT ... FROM "T_AUCTION" t0 WHERE t0."C_UID" = 1000147 //log:er.extensions.ERXAdaptorChannelDelegate.sqlLogging [WorkerThread2] === Note that each time a new EC is created (that's all right), but they all belong to the same OSC (69463522). Yet, each time there's a fetch of the same object (1000147). I must be missing something of importance; I believe there should be only the 1st one, while instead of the latter ones the fault should get fired quickly through snapshots of the OSC without a DB roundtrip. Thanks, OC >> Le 17 août 2024 à 08:48, ocs--- via Webobjects-dev >> <webobjects-dev@lists.apple.com> a écrit : >> >> Hi there, >> >> (I've solved the locks — were caused by a stray background thread which I've >> completely forgot of; and Samuel — yes, it was related to logging. D'oh.) >> >> Now it works all right and reliably, but I observe very strange behaviour: >> with the separate OSC, the direct action is, in average, considerably >> slower; and the culprit seems are DB roundtrips. I hope I am missing >> something completely obvious again... >> >> When I create my local EC for my direct action this way: >> >> === >> if (!sharedosc) sharedosc=new EOObjectStoreCoordinator() >> localec=ERXEC.newEditingContext(sharedosc) >> === >> >> almost each time the fault created through this EC is accessed, there's a DB >> roundtrip. On the other hand, if I create it this way (without any other >> change) >> >> === >> if (!sharedosc) sharedosc=EOEditingContext.defaultParentObjectStore() >> localec=ERXEC.newEditingContext(sharedosc) >> === >> >> there are no roundtrips at all. >> >> I would understand the first fetch in the separate OSC, but subsequently, it >> should just use snapshots like the default root store does, should it not? >> What am I missing? >> >> Thanks, >> OC >> >>> On 16. 8. 2024, at 18:14, ocs--- via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Hi there, >>> >>> I've got a direct action, which sometimes needs to get an object with a >>> known PK, for which I use faultWithPrimaryKeyValue. Works well for years, >>> but lately the fetches went longer, so I decided to allow it to use a >>> separate OSC not to clash with the normal database requests. >>> >>> The result is weird: >>> - sometimes, faultWithPrimaryKeyValue in the dedicated OSC is lightning >>> fast, as presumed >>> - sometimes though, it never ends?!? :-O >>> >>> It does not lock once and then stay locked, the cases are intermittent. >>> Also, it never locks when I test myself at my development machine; happens >>> on the deployment site only, sigh. I have also reasons to believe that the >>> DA does not deadlock with another thread (essentially since at the moment >>> of the first lock, nothing at all ran in parallel). >>> >>> The code looks like this: >>> === >>> static sharedosc >>> WOActionResults someAction() { >>> try { >>> boolean oscpolicy=ERXProperties.booleanForKey('ActionSpecificOSC') >>> def localec, osc >>> ... ... >>> for (... a couple of times ...) { >>> ... >>> if (some-condition-which-says-I-need-to-fetch) { >>> if (!localec) { >>> if (oscpolicy && !sharedosc) sharedosc=new >>> ERXObjectStoreCoordinator(true) >>> >>> (localec=ERXEC.newEditingContext(sharedosc?:EOEditingContext.defaultParentObjectStore())).lock() >>> // 1 >>> } >>> log "/TEMP will fetch in $localec..." // 2 >>> eo=EOUtilities.faultWithPrimaryKeyValue(localec ,'DBAuction', >>> Integer.valueOf(map.eoprimarykey)) >>> log "/TEMP ... did fetch in $localec" >>> } >>> ... >>> } >>> ... ... >>> if (localec) localec.dispose() >>> } catch (exc) { >>> some-log-which-never-happens-thus-I-know-the-above-never-threw >>> } >>> } >>> === >>> >>> When ActionSpecificOSC is off, it never ever locks. When it is on though, >>> occasionally the “will fetch” log marked // 2 is the very last thing which >>> the appropriate worker thread ever does. In other (intermittent) cases it >>> all works well. >>> >>> Aside of moving the localec.dispose to finally, which would be safer, but >>> in this case irrelevant for no exception ever happens, can you perhaps see >>> a possible culprit? >>> >>> Side question: originally, my // 1 line looked like >>> (localec=ERXEC.newEditingContext(osc)).lock(). Far as I can say, should >>> work precisely same way as the above, but did not: when the osc was null, >>> I've got an invalid EC with a null rootObjectStore. What the H.?!? >>> >>> 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/ocs%40ocs.cz >>> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >>> >>> This email sent to o...@ocs.cz >> >> _______________________________________________ >> 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/samuel%40samkar.com >> >> This email sent to sam...@samkar.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
