Thanks for the reply. Sorry for my delay in responding -- I've been out on vacation. ;-)
so the short answer is that what you propose to do is not a use c3p0 currently anticipates or supports.
an Exception in onCheckout, or the failure of a Connection test, are interpreted as an indication that the Connection is broken and should be retried. onCheckout is intended to set-up Connections for client use, but is not designed to control access to Connections or discriminate among clients. (how do you discriminate among clients in your initialization? and what sort of per-tenant initializations do you perform? do you ensure that whatever you do is undone on checkin, or consistently "overwrite" the initializations on checkout, to ensure that all pooled Connections are interchangeable on checkout?)
it wouldn't be too hard to support what you want, to define an Exception that could be thrown from onCheckout to signal not a failure but a client ejection. the Exception might indicate whether the Connection should be interpreted as broken or returned to the pool for future use, or else the library could just err conservatively and purge. but...
1) i don't want to integrate this as a new feature until i get 0.9.2-final released and start the next dev series. the current release [ 0.9.2-pre8 ] is pretty much a release candidate. if there are no showstoppers, i hope to be done this series within a few weeks.
2) i'm not sure that inside the pooling library is the right place to do what you want. do you think it might be better to wrap a facade around DataSource and do your tenant-specific stuff there? DataSource is a pretty easy interface to wrap.
that said, i'm not opposed to adding this, if it would be helpful. but it won't be part of 0.9.2.
On Dec 19, 2012, at 4:07 PM, John Hardin wrote:
> I'm working on a multi-tenant application using c3p0. I'm managing a single connection pool for all Tenants. Upon checkout, I want to test the connection as well as initialize it for use by the current Tenant (which is established early in request processing).
> ConnectionCustomizer.onCheckout() or (Unified)ConnectionTester.activeCheckConnection() seem like ideal locations for my test and initialization logic. In some cases, I want to toss the current connection, and retrieve another from the pool (or create a new connection as necessary). The "retry" built into the callers of these functions implements this very logic.
> HOWEVER, in other cases, I want to abort the current request altogether, and the caller's retry logic seems to prevent me from doing so.
> While ConnectionCustomizer.onCheckout() is declared to throw Exception, the caller catches Exception, tosses the connection, and tries again. ConnectionTester.activeCheckConnection() returns the status of the connection, but there is no status for "abort the request". So, in both locations, I see no way to abort the current request. :-(
> Any ideas?
> Thank you, in advance, for your assistance.
> -John Hardin
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> c3p0-users mailing list