fetches too often (was: weird locks) in faultWithPrimaryKeyValue
fetches too often (was: weird locks) in faultWithPrimaryKeyValue
- Subject: fetches too often (was: weird locks) in faultWithPrimaryKeyValue
- From: ocs--- via Webobjects-dev <email@hidden>
- Date: Sat, 17 Aug 2024 14:48:41 +0200
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
> <email@hidden> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden