On Apr 15, 5:09 pm, kush.de...@gmail.com wrote:

Hi. What version of WebLogic? Here is an example of best-practices
JDBC style in a WebLogic environment. You can also show me your
pool definition... What parameters do you see thrown away?
Joe Weinstein at BEA Systems

Here is the ideal standard for safe WebLogic JDBC. If you can
adopt this, many such problems will go away.  Pooling is fast,
and is best used in a quick per-invoke fashion:

/* This is how you should make any of your top-level methods
* that will do JDBC work for any of your user invokes.
*/
public void myTopLevelJDBCMethod()
{
 Connection c = null; // ALL JDBC objects should be *method*
                      // level objects to ensure thread-safety
                      // and prevent connection leaking.
                      // Define the connection object *in this
                      // method*, before the JDBC 'try' block.
 try {
   // This is *the* JDBC try block for this method. Do
   // *all* the JDBC for this method in this block.

   // Get the connection *directly from our DataSource*
   // in the try block. Do *not* get it from any method
   // that has kept a connection and is sharing it for
   // repeated use.

   c = myDataSource.getConnection();

   ... do *all* the JDBC for this method in the scope of this try
block...
   ... you *can* pass the connection or sub-objects to sub-methods
   ... but none of these methods must expect to keep or use the
   ... objects they receive after their method call completes...

   (eg)

   DoSomethingFancyWith(c);

   // Use Prepared/Callable Statements. They are faster usually,
   // Especially because we cache them transparently with the pool.
   PreparedStatement p = c.prepareStatement(...);
   ResultSet rs = p.executeQuery();
   ProcessResult(myrs);

   // Close JDBC objects in the proper order: resultset, then
statement, then connection

   rs.close(); // always close result sets ASAP at the level they
were created
   p.close(); // always close statements ASAP at the level they were
created

   ...

   // When the JDBC is finished in the try-block, close the con:
   c.close(); // always close connection ASAP in the same method
              // and block that created/obtained it.
   c = null;  // set the con to null so the finally block below
              // knows it's been taken care of.
 }
 catch (Exception e ) {
   ... do whatever, according to your needs... you do not have to
   ... have a catch block if you don't want it...
 }
 finally {
   // Always have this finally block. A finally block is *crucial*
   // to ensure the connection is closed and returned to the pool,
   // (not leaked).
   // failsafe: Do every individual thing you want to do in the
   // finally block in it's own try block-catch-ignore so everything
   // is attempted.

   try {if (c != null) c.close();} catch (Exception ignore){}
 }
}