When your application starts up, initialize PoolManager by setting up connection pools to all possible databases; I believe you said there were only 10. PoolManager has some cache which stores each connection pool under a unique name. Provide a method like allocateConnection() which takes the name of the connection pool and returns a connection from the pool.
By doing this, you eliminate the "dynamic" complexities because you assume that at some point a connection from each pool will be used. Another alternative would be to use a lazy loading scheme where upon if a call to allocateConnection() does not find a valid connection pool under the specified name, it retrieves the appropriate parameters from the "global" database, creates the connection pool, returns a connection, and caches the connection pool for future use. robert > -----Original Message----- > From: Howard Miller [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 15, 2002 8:40 AM > To: 'Struts Users Mailing List' > Subject: RE: Connection pool question > > > Wow.... now I finally have to read "Design Patterns" as well!! - sorry > Singletons and suchlike currently over my head - twenty or so > years writing > mostly assembler and Pascal! > > Your PoolManager option sounds interesting, although I don't see the > end-game. How will this handle connections to multiple arbitrary databases > which (essentially) are dynamic and defined at run-time. > > Sorry.... I'm giving you a hard time with this. Its appreciated though!! > > Howard > > -----Original Message----- > From: Robert Taylor [mailto:[EMAIL PROTECTED]] > Sent: 15 August 2002 13:26 > To: Struts Users Mailing List > Subject: RE: Connection pool question > > > Okay, but when you get a few cycles, take some time to learn > about JNDI and > datasources. It's very worth while. > > An alternative would be to create a single object which manages your > connection pools; PoolManager. Give it some static methods that allocate > connections. Initialize it when your web app cranks up. It is then > accessible to all objects in the same VM. If you had some > contentions about > having static methods, then make it a singleton. This allows you to keep > transaction management within your business tier and out of the web tier. > > Another alternative would be your solution #1, although this > means that most > likely you will be managing your transactions directly in your Action > classes :( . > > Good luck, > > robert > > > > > -----Original Message----- > > From: Howard Miller [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 15, 2002 8:04 AM > > To: 'Struts Users Mailing List' > > Subject: RE: Connection pool question > > > > > > Thanks Robert, > > > > I must confess I don't get it. I was under the impression that > > JNDI was just > > an abstraction mechanism for looking up objects in a choice of > > directories. > > > > The information about my databases is already stored in tables in the > > "central" database. Looking up the information is trivial, it > is the best > > way to actually connect to the databases that I am concerned about. I.e, > > once I have the connection object (or connection pool object) > > where do I put > > it? > > > > Also, I am currently rather negative about trying to pick up yet another > > Java technology when I already have too many half learnt > > technologies on the > > go!! (Brain melting!!) > > > > Regards, > > > > -----Original Message----- > > From: Robert Taylor [mailto:[EMAIL PROTECTED]] > > Sent: 15 August 2002 12:47 > > To: Struts Users Mailing List > > Subject: RE: Connection pool question > > > > > > > > Standardization: All servlet containers that support the Servlet2.3 spec > > must provide a way to look up data sources via JNDI. All or most > > application > > servers support general object location via JNDI. > > > > Simplicity: To look up a data source, all you have is the > following code. > > Context ctx = new InitialContext(); > > DataSource ds = (DataSource)ctx.lookup( "jdbc/<data source name>" ); > > > > Flexibility: You can define your datasources in some file > external to your > > code, such as a properties or xml file. This allows you to make changes > > without affecting your code. > > > > Decoupling: By accessing your datasources via JNDI lookup, your business > > objects don't depend on the web tier to provide access via the > > application, > > session, or request scope. This makes them reusable in other > applications. > > > > Those are four reasons I can think of. There are probably more. > Craig, has > > discussed the "best practices way" of using data sources in > > Struts. You may > > want to browser the archives. > > > > HTH, > > > > robert > > > > > -----Original Message----- > > > From: Howard Miller [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, August 15, 2002 7:33 AM > > > To: 'Struts Users Mailing List' > > > Subject: RE: Connection pool question > > > > > > > > > Thanks, > > > > > > I don't know much about JNDI (apart from in general terms what > > it is); why > > > would doing it this way be a good thing? > > > > > > Howard > > > > > > > -----Original Message----- > > > > From: Robert Taylor [mailto:[EMAIL PROTECTED]] > > > > Sent: 15 August 2002 12:10 > > > > To: Struts Users Mailing List > > > > Subject: RE: Connection pool question > > > > > > > > One solution might be to define several datasources in your > > > > application/servlet container where each datasource > corresponds to its > > > > respective database. > > > > Then use JNDI to access the datasources from your application. > > > > > > > > robert > > > > > > > > -----Original Message----- > > > > From: Howard Miller [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, August 15, 2002 6:47 AM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: Connection pool question > > > > > > > > Hi, > > > > > > > > Newbie, JDBC connection pool question: > > > > > > > > My application uses a central control database. > This is ok, and I > > > > can see how to use a connection pool for my application to > > access this. > > > > > > > > BUT... The application allows a user to recover > data from a range of > > > > additional databases. That is the central database verified > > > logins etc and > > > > then lists a number of databases for the user to connect to. > > > > > > > > I am very unsure how to handle this "sub > -connection". I have a > > > > number of thoughts... all bad: > > > > 1. Set up connection pools to ALL possible > databases (there are less > > > > than 10), at the start in the application scope. > > > > 2. Set up a dedicated connection in the session scope. > > > > 3. Set up a dedicated connection in the request > scope (cgi style). > > > > > > > > I don't like any of these answers. Anybody have > experience of this > > > > sort of "dynamic database connection" or have any thoughts. > > > > > > > > Regards, << File: ATT00047.txt >> << File: ATT203342.txt >> > > > > > > -- > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
