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]>
