commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Speirs <wspe...@apache.org>
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.

Bill-
On Dec 8, 2011 5:52 PM, "Cameron, Scott" <scott.cameron@sap.com> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

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