> 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: [email protected] For additional commands, e-mail: [email protected]
