Re: Connection pooling + WebObjects
Re: Connection pooling + WebObjects
- Subject: Re: Connection pooling + WebObjects
- From: Mike Schrag <email@hidden>
- Date: Mon, 12 May 2008 17:13:40 -0400
Is this implemented through "object store coordinator pooling"? I
was wondering about that recently.
Yep ... It's actually the same plumbing as multiple instance
synchronization, to shuffle the data around with the exception that in
local syncing, it can actually inject the snapshots directly into the
pooled EODatabases. In Wonder, it does a round robin of your OSC, but
(if i recall) associates a session with an OSC (if there is one) and a
thread with an OSC. So once you have a session, you stay on a
particular OSC, and for a particular thread, once you start performing
operations, your thread will stay on that same OSC, to try to minimize
oddities of ending up with two EO's from two different stacks, etc.
As far as the injecting of snapshots, this is a blessing and a
curse ... I mentioned it in the previous post, but when we inject the
snapshot, it has a refcount of zero. In EOF, snapshots only get
released when the DROP to zero. There is no reaper thread for the
snapshot cache. This means that if you push a snapshot to another
EODatabase that is never fetched into an EC in that OSC, it will never
get released. I recently committed some API to control this (so you
can turn off snapshot syncing per-OSC and just do GID-based
notification). For many apps, you'll never notice, because most data
is touched multiple times, but server types of apps (with bulk imports
of read-mostly data, for instance), might be an issue. Remote syncing
does not have this problem, because it's already GID-only.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden