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 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]
