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> 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) > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com