Hi,
Using the same OSC for both the RR-WorkerThreads and long-response background
threads may result in deadlocks in a heavier load scenario (which is bad for
your karma)
Using en extra OSC for every background task may consume too much memory.
Fortunately there exists the combination of ERX
OC,
I do not know your app and deployment setup but usually, I know that keeping
things simple is usually a good thing and a single instance app can be very
efficient with it's database by assuming it's cache is valid. Creating a
complete EOF stack for a single request seems very overkill for m
Samuel,
> On 17. 8. 2024, at 15:59, Samuel Pelletier 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, o
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 = ne
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
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, co
Hi OC,
Last week, I spend some time to optimise an app after seeing strange behaviour,
the cpu usage of this app was growing with time with no logical explaination.
Your case sound similar to me so I share my experience on this.
During these high cpu usage period, the app had strange locking an
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 res
