commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Speirs <>
Subject RE: [dbcp] Handling many different user accounts over time
Date Thu, 08 Dec 2011 23:06:23 GMT
If you have specific ideas, open a JIRA ticket and we can look into it.

On Dec 8, 2011 5:52 PM, "Cameron, Scott" <> wrote:

> > What do you mean, "across all users"? Do you have different connection
> > strings (user/pass) for each person who connects to your database?
> It's a slightly mixed bag as the app is multi-tenanted.  We have some
> connection strings used by nearly everybody for certain things.  Some
> connection strings are assigned to an "organization" and will be used
> by all users in that org.  And some connection strings are unique for
> each individual user.
> > Do I understand correctly, if I show up to your site as user wspeirs,
> > then I'm connecting to your database as wspeirs? If so, then why
> > wouldn't you simply create a connection for that user and store it in
> > the user's session? When the session is destroyed, you close the
> > connection. There is a bit more "start-up" time in creating the
> > connection when they first show up, but it'll be live and active
> > during the rest of the time they are there.
> Even if the connections weren't sometimes shared across users, the
> component that manages connections doesn't have any knowledge of
> application-level concepts like session. It's job is just to manage
> connections, which can potentially have a different lifecycle than
> session.
> We're thinking that maybe we can rely on "maxIdle" to evict unused
> connections.  The downside to this is that the default minimum
> idle time before eviction is 30 minutes and can't be configured. But
> maybe that will be OK.
> It would be nice to have more control over the object pool inside
> the pooled data source classes as that seems to be where most of the
> interesting tweakable pooling features live.  But only a very small
> number of options are exposed to data source consumers.
> --
> scott
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message