Re: Connection pooling + WebObjects
Re: Connection pooling + WebObjects
- Subject: Re: Connection pooling + WebObjects
- From: Kieran Kelleher <email@hidden>
- Date: Mon, 12 May 2008 21:06:23 -0400
So if I have Wonder OSC synchronization going on inside a single app
and I lock an OSC (in a background long running thread for example),
how does that affect the synchronization between it and other OSCs
while it is locked? How are snapshots affected in the locked OSC
during the lock period while the same snapshots change in other OSCs
and vice-versa?
Kieran
On May 12, 2008, at 5:13 PM, Mike Schrag wrote:
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
_______________________________________________
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