-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kevin,
[EMAIL PROTECTED] wrote:
| I tested mysql and it is using tcp/ip. "mysql -h 127.0.0.1 -u javauser
| -p" works fine.
| Also the MSQLAdmin program shows it is connecting to the correct port 3306
Okay, good. Any software firewalls enabled? The default firewall for
recent Windows versions does not prohibit any localhost traffic that I
know of.
| I see your point about purring the resource in conf/context.xml, I will
| move it.
| But from reading online forums, I have come across two suggestions:
| 1) put a context.xml in the WEB-INF dir of you webapp
| 2) put the <Context> in <tomcat>\conf\localhost\<webappname>.xml
|
| I would guess that 1) is correct, so that is what I did. Attached is my
| current context.xml from this webapp
Both are acceptable, but #1 is more straightforward and, IMO, easier to
maintain.
| So now Tomcat starts with no errors, but when I try to run my jsp which
| uses a DAO in java I get errors:
|
| org.apache.jasper.JasperException: Cannot create JDBC driver of class ''
| for connect URL 'null'
| [snip]
| So why can't it find a driver[?]
| I put the mysql-connector-java-5.1.5-bin.jar in <tomcat>\common\lib
For best result, you should put it in <tomcat>/common/lib, though
various other strategies are available if you have other requirements.
I'm not sure why there are all those 'null' strings in there... I think
either Tomcat or DBCP has a (small) bug that gives you all those nulls
when the JDBC library isn't available for whatever reason -- at least,
that's what seems to happen very frequently to posters on this list.
I think the problem might be the separation of <Resource> into
<Resource> and <ResourceParams>. I used to use these separately back in
TC 4.1.x, but it appears that there's a shorthand that may work better
for you. Here's what I have in my context.xml for our application.
Fill-in the appropriate values for your configuration. It's much easier
to read than all those nested elements, too.
~ <Resource name="@DATASOURCE_REF@"
~ auth="Container"
~ type="javax.sql.DataSource"
~ maxActive="1"
~ maxIdle="1"
~ maxWait="10000"
~ url="@DATABASE_URL@"
~ username="@DATABASE_USERNAME@"
~ password="@DATABASE_PASSWORD@"
~ driverClassName="@DATABASE_DRIVER@"
~ removeAbandoned="true"
~ removeAbandonedTimeout="30"
~ logAbandoned="true"
~ testOnBorrow="true"
~ validationQuery="SELECT 1"
~ />
Just a quick comment on programming style, etc.:
| public ConversionDAO() throws SQLException, NamingException
| {
| Context init = new InitialContext();
| Context ctx = (Context) init.lookup("java:comp/env");
| DataSource ds = (DataSource) ctx.lookup("jdbc/CurrencyDB");
|
| con = ds.getConnection(); // THIS IS LINE 23
| select = con.prepareStatement("SELECT rate FROM exchange
| WHERE src = ? and dst = ?");
| update = con.prepareStatement("UPDATE Exchange SET rate = ?
| WHERE src = ? NAD dst = ?");
| }
I highly recommend that you do /not/ do what you are doing, here.
Specifically, don't grab a JDBC Connection at object creation time and
hold it forever. This completely defeats the purpose of the connection
pool: to use connections only when necessary.
I see what you're trying to do: improve performance by preparing SQL
statements in advance and re-using them. The truth is:
1) Prepared statements are faster than non-prepared statements, but in
truth, you're not saving all that much time. Any performance benefit you
get from the above code is completely gone by hoarding a connection in
your DAO.
2) Both Connector/J and MySQL server can both cache prepared statements
for you. In that case, calling Connection.prepareStatement(some
statement) can be nice and fast even if you are technically repeating
the calls over and over again. Also, recent versions of Connector/J have
disabled server-side prepared statements because they simply do not work
properly, so a driver-based prepared statement cache is a nice feature.
Here's another reason not to do this: you may choose during runtime to
change something about the connection pool (like make all connections
read-only or something). If you don't grab a new connection each time,
the behavior will be unexpected.
Assuming you are writing lots of DAOs like this, I recommend moving the
code to grab a database connection into another utility object so all
the code is in the same place. Something like this:
public class DAOHelper
{
~ public static Connection getConnection()
~ throws SQLException, NamingException
~ {
~ Context init = new InitialContext();
~ Context ctx = (Context) init.lookup("java:comp/env");
~ DataSource ds = (DataSource) ctx.lookup("jdbc/CurrencyDB");
~ if(null == ds)
~ throw new NamingException("Could not find JNDI DataSource");
~ return ds.getConnection();
~ }
}
Then, all your DAOs can use this code to get a connection without having
to repeat that (albeit small) amount of code.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfB4gkACgkQ9CaO5/Lv0PAyrQCdFKEMr+EgdHN6EQp8mGm2jJ7Z
7IkAn0OZIcynRy0KaYsXwW9bZy+3aDCu
=HWmr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
