Adding another idea, Use a pool manager with an API for adding a database to the manager. I'm sure Tomcat has an api as well to hook into the DataSources of a running instance and edit them...look at the tomcat admin source. So, setup your pools to your different database dynamically as they are opened.....if this is possible for you. I don't know how many different dbs there possibly are for your application and what you user load is projected to be, but sooner or later if this can keep growing your pools will be taking up more and more memory as more and more pools with their own numbers of connections and memory usage are added.
Wade -----Original Message----- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 8:55 AM To: Tomcat Users List Subject: RE: Managing DB connections via HttpSessionListener Howdy, A couple of ideas: 1. If the number of possible DBs is small (and small is objective: I would do this even if there were five or ten possible DBs), you could still create pools for them. They'd probably be very lenient pools (0-1 min connections, short idle time before closing). 2. I don't think doing it in the Session is a great idea. Sessions are too long-lived for this: you don't want to hold a connection that long. Gotta go... Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Morten >Sent: Monday, November 17, 2003 8:10 AM >To: [EMAIL PROTECTED] >Subject: Managing DB connections via HttpSessionListener > > >Hi. I have a setup where I cannot just use a DataSource with pooled >connections. The user logs in, performs some operations against a >database by giving a host, port and sid, and quits again. > >I would prefer to not having to open/close the DB connection each time, >but as the DB is dynamically selected, I cannot predefine it in a pool >configuration. > >I've considered implementing the HttpSessionListener interface and close >the connection in the sessionDestroyed(..); method, would that work? I >suspect that it can be dangerous to keep the connection obect in the >session as that may get serialized to disk, so I'd be storing a key in >the session that allows me to look up the connection and close it. > >Any other suggestions on how to accomplish this sort of setup in a >somewhat elegant manner? > >Br, > >Morten > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
