To integrate the synchronizer, just add this in your Application
constructor:
ERXObjectStoreCoordinatorSynchronizer.initialize();
That is all I have in one of my current ongoing projects. I don't use
ERXObjectStoreCoordinatorPool at all. In that particular app, the R-R
loop stuff typically
You guys think of eveything. My most recent implementation is working
well, and in retrospect I really shouldn't have expected my scheduler
ec to play well with the session ecs in the same osc. That ec can
stay locked for 15 seconds at a time while the session ecs may be
locked hundreds o
The only real downside is memory consumption ... For every OSC you
have, you have duplicate snapshot caches. If you have mostly
isolated data sets for each session, then this may not matter at all,
though, and depending on the use-case, this may actually make lots of
things easier. This i
As long as you use Wonder's ERXObjectStoreCoordinatorSynchronizer
class, notifications are all taken care of for you. According to Mike
Schrag, this has been well tested under heavy load and I have seen
zero issues with it .. in fact you will have issues if you don't
use it.
On Aug 8,
On Aug 7, 2007, at 12:07 PM, Kieran Kelleher wrote:
2) Use a separate ObjectStoreCoordinator for your background thread
to avoid locking conflicts
What are the downsides of doing this? I have to admit, my object
store coordinator recollection is sketchy. Do you have to implement
your o
Thanks for the tips. BTW - I do use and highly recommend
erxgenericrecord's did and will extensions. I don't know how I got by
without them. In this case this was the apparently easier way.
Well, it locked up again today so I gave my scheduler ec its own
erxosc and I'll see how that goe
1) Mike Schrags advice of using GlobalIDs for passing around EO's
between threads is good advice.*
Note: I *believe* all the oddities of this scenario when you use
autolocking w/ coalescing is now properly fixed as of a couple weeks
ago ... But passing around GID's between threads is still no
Hi John,
Just some general comments:
1) Mike Schrags advice of using GlobalIDs for passing around EO's
between threads is good advice.
2) Use a separate ObjectStoreCoordinator for your background thread
to avoid locking conflicts
3) Use Wonder's ERXObjectStoreCoordinator to automatically
I read the recent post on a concurrency problem and wondered if it is
similar to a problem that I recently ran into, or maybe I'm just
making another EC mistake.
I have a background thread that does background order scheduling. It
needs to be kept abreast of specific changes in objects. T
