The main benefit is speed. To initialize a connection, you could be
looking at 140ms just to get the connection up and going. Pooling
reuses the created connections so your delay is just your SQL code, not
the connection initialization.
It's really easy to get one setup with actions. First, install the dbcp
from commons into your webapp, then at the top of your
struts-config.xml:
<data-sources>
<data-source
type="org.apache.commons.dbcp.BasicDataSource">
<set-property
property="defaultAutoCommit"
value="false"/>
<set-property
property="defaultReadOnly "
value="false"/>
<set-property
property="driverClassName"
value="com.microsoft.jdbc.sqlserver.SQLServerDriver"/>
<set-property
property="maxActive"
value="20"/>
<set-property
property="maxIdle "
value="10"/>
<set-property
property="password"
value="1234"/>
<set-property
property="url"
value="jdbc:microsoft:sqlserver://127.0.0.1:1433;databaseName=X"/>
<set-property
property="user"
value="technolojesus"/>
</data-source>
</data-sources>
Then, in your action, you can access your datasource via:
execute(......)
{
DataSource ds = this.getDataSource(request);
}
Regards,
Jake
| -----Original Message-----
| From: Howard Miller [mailto:[EMAIL PROTECTED]]
| Sent: Thursday, August 15, 2002 7: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: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]>
