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: Jérémy DE ROYER via Webobjects-dev <email@hidden>
- Date: Sun, 18 Aug 2024 08:33:23 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ingencys.net; dmarc=pass action=none header.from=ingencys.net; dkim=pass header.d=ingencys.net; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=J/5DHjRdQR0cznN+QmPPjBvXk82iTPMolTZQXP35WrI=; b=Z9bL6jPfHEsngvPEnTitc8euY/xc2E+MI6msfDAibqdCxpjA8kkphGKRKTROErlGYiCCqXXMVYivS7lBKCmMYarrisOep9zUZq2V9IZdgk2sYcUdcqKLCQDLbNjeMLxeTTrJfCGUsYMJQTY/NwCtTY7cge9vbjDUyJVoY5RHGtHzgMSh+q7yHw5PILyyvjFISLlORUVTdYALZqy1ehkGb/4yym4XPLynODTckmqE+pRhllO151dxJY87cNkgXqtJNv2XeLPYze+8OBL8ryc6DP0BhILKUELhhVvict7XCD/7v7SJcz17Ap1AYbmzbpVv5ryb2tCwYxgvLZnw5JZwCg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=KBM6O8Y2ufK5psJHiAXDy4uljSQB9dgN3nt4fLKjPbfPFm8fphNdKLCF2/LMitVNn2puUYi1xYHsLfyuD7GnJPkFwjOlB9/6AAJDFzdkQmUvqyMSn/qDCY/31RnkXjUtbKEzXan4xKvNl2KOUEkhzm3D1X3VsMizvonaPv248roa2yWfKhv8MzzCp/3xQ7zlEBxR2pK2tUG3YMyIdDsV2RKb7rzISQFDJyYhQD4VX+wygghAq7oa4VK+PERjuTpXPw5R9Q7MBv9q4U2sh64HrtRvyckhUulUHu/Too5mlM1ufzT/2wHKrCscfTISoPY0qiin9yUym8WhHSCE0uGc/g==
- Thread-topic: fetches too often (was: weird locks) in faultWithPrimaryKeyValue
Hi,
As Samuel wrote, I do create new OSC when I make large export / report without
any editing.
So, it creates a new dedicated connexion to the database and does not slow down
the users using the shared editing context / main connexion.
ERXObjectStoreCoordinator _tmpObjectStoreCoordinator = new
ERXObjectStoreCoordinator(true);
WOSession _localSession = new WOSession(_tmpObjectStoreCoordinator);
_localSession.defaultEditingContext().setUndoManager(null);
_localSession.defaultEditingContext().lock();
and after the process
_localSession.defaultEditingContext().unlock();
_localSession.defaultEditingContext().dispose();
_localSession.terminate();
_tmpObjectStoreCoordinator.dispose();
Hope it helps,
Jérémy
Le 17 août 2024 à 15:59, Samuel Pelletier via Webobjects-dev
<email@hidden> a écrit :
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<mailto: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<mailto:email@hidden>
_______________________________________________
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<mailto: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