OC, 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 never create new OSC in my apps, why are you creating OSC like this ? The only real case I see is large report generations in background thread and even for this batching fetches do a good job. If your fetches are long, check your database indexes. Regards, Samuel > 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 >> >> 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
