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
