Well, you can also setup connection pools in the application container in your servlet.xml, Tomcat's site does a nice job of explaining how to do it.
Ignore the design patterns thing for a moment... The real question is how often or concurrently would you be calling to the same database under the same login/password? If you are looking at only 3 or 5 concurrent users of connections or only one use for a specific connection, then you are better doing what you must already be doing which is creating connections on the fly. If you do have lots of concurrent users logging in with the same credentials, then you will see a major speed improvement with connection pooling. If anything, setup a pool for the connection that looks up the connection information ;-) -Jacob | -----Original Message----- | From: Howard Miller [mailto:[EMAIL PROTECTED]] | Sent: Thursday, August 15, 2002 7: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:struts-user- | [EMAIL PROTECTED]> | For additional commands, e-mail: <mailto:struts-user- | [EMAIL PROTECTED]> | | --- | Incoming mail is certified Virus Free. | Checked by AVG anti-virus system (http://www.grisoft.com). | Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 | --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
