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
|