tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Moss" <billm...@hotmail.com>
Subject RE: DBTags and connection pooling, jndi, etc.
Date Wed, 12 Dec 2001 15:37:03 GMT
Using the web.xml and poolman.xml from your original post, I get:

javax.servlet.ServletException: java.sql.SQLException: No suitable driver

I'm using Sybase and jconn2.jar (which I've placed in every conceivable 
location) with Tomcat 4.0. I switched from Resin because I found deploying 
webapps easier in Tomcat, but if DBTags and pooling work in Resin with your 
instructions I will go back!

Did you have any trouble compiling DBTags? I thought I read a message 
mentioning it?

Thanks a lot for your help,
Bill




>From wim.bervoets@iconmedialab.com Wed, 12 Dec 2001 07:21:52 -0800
X-Mailer: Internet Mail Service (5.5.2653.19)

Hi Bill,

I got it working:

Resin 2.0.2 / DBTAGS / PoolMan

There are a few things you have to do to get it working:

In the DBTags source:

ConnectionTag.java:

In the doEndTag function add Class.forName(_driver).newInstance();

like this:

if (_driver != null) {
	Class.forName(_driver);
       Class.forName(_driver).newInstance();
}

Also in:

BaseGetterTag.java

   /**
    * If I understand the new JSP spec correctly, release()
    * is NOT called between invocations of a cached taglib,
    * so I guess we do it manually or write a new method.
    *
    * @return EVAL_PAGE constant
    */
   public int doEndTag() {
	release()   => remove this !!!
     return EVAL_PAGE;
   }

More info see:
http://www.caucho.com/quercus/bugtrack/view.xtp?bugreport_id=135

(fixes a null pointer exception with Resin)


My xml configuration:

in web.xml:

<context-param>
       <param-name>dbURL</param-name>
       <param-value>jdbc:poolman://wimsbios</param-value>
       <description>
         Which Database to access and where it is located
       </description>
     </context-param>

     <context-param>
       <param-name>mysqlDriver</param-name>
       <param-value>com.codestudio.sql.PoolMan</param-value>
       <description>
         JDBC Driver
       </description>
     </context-param>

     <context-param>
       <param-name>dbUserId</param-name>
       <param-value>mysql</param-value>
       <description>
         DB user id
       </description>
     </context-param>

     <context-param>
       <param-name>dbPassword</param-name>
       <param-value>mysql</param-value>
       <description>
         DB password
       </description>
     </context-param>

poolman.xml:
------------

<poolman>

   <management-mode>local</management-mode>

   <datasource>

     <!-- ============================== -->
     <!-- Physical Connection Attributes -->
     <!-- ============================== -->

     <!-- Standard JDBC Driver info -->
     <dbname>wimsbios</dbname>
     <jndiName>jndi-wimsbios</jndiName>
     <driver>org.gjt.mm.mysql.Driver</driver>
     <url>jdbc:mysql://localhost/wimsbios</url>
     <username>mysql</username>
     <password>mysql</password>

     <!-- Transaction Isolation Level, an optional value that,    -->
     <!-- if present, must be one of the following:               -->
     <!--   NONE                                                  -->
     <!--   READ_COMMITTED                                        -->
     <!--   READ_UNCOMMITTED                                      -->
     <!--   REPEATABLE_READ                                       -->
     <!--   SERIALIZABLE                                          -->
     <!-- If the value is misspelled or ommitted, the default     -->
     <!-- will be applied. The value is not case-sensitive.       -->
     <!-- DEFAULT: READ COMITTED                                  -->
     <txIsolationLevel>READ_COMMITTED</txIsolationLevel>


     <!-- If the following element is set to true, then PoolMan's  -->
     <!-- scrollable/updatable ResultSet will not be used, and the -->
     <!-- underlying driver's ResultSet will be used instead. This -->
     <!-- provides a performance gain in certain rare instances at -->
     <!-- the expense of functionality.                            -->
     <!-- DEFAULT: false                                           -->
     <nativeResults>false</nativeResults>

     <!-- If set to true, the following attribute will cause  -->
     <!-- all PreparedStatements to be pooled and reused      -->
     <!-- rather than recreated with each invocation.         -->
     <!-- DEFAULT: true                                       -->
     <poolPreparedStatements>true</poolPreparedStatements>


     <!-- ======================== -->
     <!-- Pool Behavior Attributes -->
     <!-- ======================== -->

     <!-- Connections created when the pool is instantiated -->
     <!-- DEFAULT: 1                                        -->
     <initialConnections>2</initialConnections>

     <!-- The pool will never shrink below this number -->
     <!-- DEFAULT: 0                                   -->
     <minimumSize>0</minimumSize>

     <!-- The pool will never grow larger than this value -->
     <maximumSize>10</maximumSize>

     <!-- If the maximum size of a pool is reached but requests  -->
     <!-- are still waiting on objects, PoolMan will create new  -->
     <!-- emergency objects if this value is set to true. This   -->
     <!-- will temporarily increase the size of the pool, but    -->
     <!-- the pool will shrink back down to acceptable size      -->
     <!-- automatically when the skimmer activates. If this      -->
     <!-- value is set to false, the requests will sit and wait  -->
     <!-- until an object is available.                          -->
     <!-- DEFAULT: true                                          -->
     <maximumSoft>true</maximumSoft>

     <!-- The connection will be destroyed after living for a     -->
     <!-- duration of this value. IN SECONDS.                     -->
     <!-- DEFAULT: 1200 (20 minutes)                              -->
     <connectionTimeout>600</connectionTimeout>

     <!-- A user will lose a Connection and it will automatically -->
     <!-- return to its pool after the duration greater than or   -->
     <!-- equal to this value. If this value is set to 0 or less, -->
     <!-- no user timeout will be enforced. IN SECONDS.           -->
     <!-- DEFAULT: 20                                             -->
     <userTimeout>12</userTimeout>

     <!-- How frequently each object's connection timeout and     -->
     <!-- user timeout values will be examined for collection.    -->
     <!-- IN SECONDS.                                             -->
     <!-- DEFAULT: 420 (7 minutes)                                -->
     <skimmerFrequency>300</skimmerFrequency>

     <!-- Each time the pool is sized down, how many connections  -->
     <!-- should be removed from it? This value prevents backing  -->
     <!-- off the pool too quickly.                               -->
     <shrinkBy>10</shrinkBy>

     <!-- Where should log and debug information be printed?      -->
     <!-- DEFAULT: System.out                                     -->
     <logFile>testdb.log</logFile>

     <!-- If set to true, the logger will display verbose info    -->
     <!-- DEFAULT: false                                          -->
     <debugging>false</debugging>

     <!-- XA Connection Attributes   -->
     <!-- NOTE: MEASURED IN SECONDS. -->
     <transactionTimeout>100</transactionTimeout>

     <!-- Query Cache Attributes-->

     <!-- If enabled, queries will be cached. The cache is        -->
     <!-- asynchronously updated in the background.               -->
     <!-- DEFAULT: false                                          -->
     <cacheEnabled>true</cacheEnabled>

     <!-- The maximum number of query/ResultSet pairs the         -->
     <!-- cache can contain.                                      -->
     <!-- DEFAULT: 5                                              -->
     <cacheSize>10</cacheSize>

     <!-- How long the cache waits before re-loading its          -->
     <!-- ResultSets from the underlying database.                -->
     <!-- IN SECONDS.                                             -->
     <!-- DEFAULT: 30                                             -->
     <cacheRefreshInterval>120</cacheRefreshInterval>

     <!-- A SQL statement to be executed when the pool is created.-->
     <!-- DEFAULT: none                                           -->
     <!--
     <initialPoolSQL>
     	insert into users values(32, 'xml')
     </initialPoolSQL>
     -->

     <!-- A SQL statement to be excuted every time a Connection   -->
     <!-- is accessed.                                            -->
     <!-- DEFAULT: none                                           -->
     <!--
     <initialConnectionSQL>
	insert into users values(1010, 'con')
     </initialConnectionSQL>
     -->

     <!-- Whether a SQLException should cause the Connection to   -->
     <!-- be removed from the pool and destroyed.                 -->
     <!-- DEFAULT: false                                          -->
     <removeOnExceptions>false</removeOnExceptions>

   </datasource>

   <!-- NOTE: You could add more <datasource> entries and create -->
   <!-- multiple pools, if you so desired.                       -->


   <!-- ========================================= -->
   <!-- Admin via JMX HTML Adapter. Disable this  -->
   <!-- (at least comment it out) for production  -->
   <!-- environments. When enabled, point your    -->
   <!-- web browser to the localhost:[port] to    -->
   <!-- view the JMX html admin agent.            -->
   <!-- This agent is not created if the          -->
   <!-- management-mode element above is set      -->
   <!-- to "local" instead of to "jmx"            -->
   <!-- ========================================= -->
<!--
   <admin-agent>
     <class>com.sun.jdmk.comm.HtmlAdaptorServer</class>
     <name>Adaptor:name=html</name>
     <maxClients>10</maxClients>
     <port>8082</port>
   </admin-agent>
-->

</poolman>

I'm using poolman 2.1 beta and mysql 2.0.7 jdbc driver.

What are the error messages you are receiving ?

Best regards,
Wim Bervoets


 > -----Original Message-----
 > From: Bill Moss [mailto:billmoss@hotmail.com]
 > Sent: woensdag 12 december 2001 15:50
 > To: taglibs-user@jakarta.apache.org
 > Subject: DBTags and connection pooling, jndi, etc.
 >
 >
 > How does one configure Tomcat & DBTags to use a pool manager
 > like Poolman?
 >
 > There were a few posts about this but nothing concrete. Is
 > anyone pooling
 > DBTags connections? I'd like at least to pool and ideally to
 > pool using a
 > jndiName... Any configuration on basic datasource or jndi
 > pooling would be
 > very helpful (e.g. web.xml, proper jars, classpath, jdk/j2ee, etc.).
 >
 > Were Wim's
 > [http://www.mail-archive.com/taglibs-user@jakarta.apache.org/m
 > sg00957.html]
 > config settings correct?
 >
 > I have the poolman-webapp demo working with my db, but it
 > uses Struts and
 > Velocity to demo.
 >
 > Thanks,
 > Bill
 >
 > _________________________________________________________________
 > Chat with friends online, try MSN Messenger: http://messenger.msn.com
 >
 >
 > --
 > To unsubscribe, e-mail:
<mailto:taglibs-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:taglibs-user-help@jakarta.apache.org>



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>


Mime
View raw message