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 uses the default OSC and I have one other "sharedInstance" OSC that gets used for all ec's created in background tasks. Occasionally for 20 minute "hammer the database" infrequent background tasks, I may create an OSC temporarily just for that task.
I implemented this a while back after I found that using the default OSC for intensive-EOF background tasks,slowed down the app responsiveness (including some timeouts) for user R-R EOF activity.
Since I added isolated all background long running tasks to a different OSC than the default (being used for sessions) all is working smoothly.
HTH, Kieran
On Aug 8, 2007, at 3:26 PM, John Larson wrote: 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 of time during that time. Also there are thousands of transactions at a time. I think I was just asking for trouble putting dogs and cats in the same room.
I didn't worry much about synchronization since the intersection of changed data between the two stores is small, but I am getting object not found errors now when the session fires faults on the inconsequential objects attached to relationships that the scheduler is making. (inconsequential in that the session components doesnt need them to do their thing.) I imagine its because there is no synchronization between the stores. Instead of setting the tolerant gid pattern property, can I get a more reliable solution with the Synchronizer class? If so, does that go in the Application constructor to make sure the coordinators get hooked up? Lastly, I assume that the default ERXApp object store is a Erxosc?
If I can figure it out, I'd really think I could contribute to the wiki on this topic if you'd all like. John On Aug 8, 2007, at 1:38 PM, Kieran Kelleher < email@hidden> wrote: 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, 2007, at 1:57 PM, Ken Anderson wrote:
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 own method for notifications between coordinators?
Thanks, Ken
|