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 PROTECTED]>
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
