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: ocs--- via Webobjects-dev <email@hidden>
- Date: Sun, 18 Aug 2024 13:10:18 +0200
Samuel,
> On 17. 8. 2024, at 15:59, Samuel Pelletier <email@hidden> 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
>> <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