Re: fetches too often (was: weird locks) in faultWithPrimaryKeyValue
Re: fetches too often (was: weird locks) in faultWithPrimaryKeyValue
- Subject: Re: fetches too often (was: weird locks) in faultWithPrimaryKeyValue
- From: Samuel Pelletier via Webobjects-dev <email@hidden>
- Date: Sat, 17 Aug 2024 09:59:54 -0400
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
> <email@hidden> 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
>> <email@hidden <mailto: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
>> <mailto: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
_______________________________________________
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