In a connection pooling implementation the close method of connection is overriddent 
to return it to the connection pool.

So it would be

conn.close();



-----Original Message-----
From: Caroline Jen [mailto:[EMAIL PROTECTED]
Sent: 13 September 2004 21:38
To: Tomcat Users List; [EMAIL PROTECTED]
Subject: RE: [OFF-TOPIC]Yoav --> RE: Some pretty basic Tomcat
ConnectionPooling Questions????


I saw your Tomcat connection pool class.

Your class opens and gets a 'conn' object from the
connection pool.  Where in your code "returns" the
'conn' object for use?  Should there be a statemenet
like:

     return conn;

somewhere?

1. Declaration of private global variables:
<code>
   private Context ctx = null;
   private DataSource ds = null;
   private Connection conn;
</code>

2. an init() method:
<code>
// "init" does DataSource lookup
   public void init(ServletConfig config) throws
ServletException {
      super.init(config);
      try {
         ctx = new InitialContext();
         if(ctx == null) {
            throw new Exception("No Context");
         }
         ds =
(DataSource)ctx.lookup("java:comp/env/jdbc/mb");
      } // end try block
      catch(Exception e) {
         e.printStackTrace();
      }
   } // end init()
</code>

3. an openConnection() method:
<code>
   private void openConnection() {
      try {
         if(ds != null) {
            conn = ds.getConnection();
            if(conn != null) {
               message = "Got Connection to DB " +
conn.toString();
               }
            }
         } // end try block
      catch(Exception e) {
         e.printStackTrace();
         }
      } //end method openConnection()
</code>

4. a destroy() method that nulls the DataSource:
<code>
   public void destroy() {
   ds = null;
   }
</code>
--- "Luke (Terry) Vanderfluit" <[EMAIL PROTECTED]>
wrote:

> Hi Yoav and all,
> 
> Thanks for your reply,
> 
> > But you went a bit too far: the DataSource lookup
> is potentially
> > expensive.  That you can do in the init() method
> and keep a reference to
> > the DataSource, because keeping that reference
> doesn't use a connection
> > resource.
> > Then in your servlet methods, get a connection
> from the DataSource, use
> > it, and release it.
> > In your servlet destroy method, null out your
> DataSource reference. 
> > So the DataSource lookup is done once, the
> DataSource reference is kept
> > as a private non-static member variable of the
> servlet class, and the
> > Connenctions are used only within methods, they're
> not class member
> > variables.
> 
> So now I have changed my code to:
> 1. Declaration of private global variables:
> <code>
>    private Context ctx = null;
>    private DataSource ds = null;
>    private Connection conn;
> </code>
> 
> 2. an init() method:
> <code>
> // "init" does DataSource lookup
>    public void init(ServletConfig config) throws
> ServletException {
>       super.init(config);
>       try {
>          ctx = new InitialContext();
>          if(ctx == null) {
>             throw new Exception("No Context");
>          }
>          ds =
> (DataSource)ctx.lookup("java:comp/env/jdbc/mb");
>       } // end try block
>       catch(Exception e) {
>          e.printStackTrace();
>       }
>    } // end init()
> </code>
> 
> 3. an openConnection() method:
> <code>
>    private void openConnection() {
>       try {
>          if(ds != null) {
>             conn = ds.getConnection();
>             if(conn != null) {
>                message = "Got Connection to DB " +
> conn.toString();
>                }
>             }
>          } // end try block
>       catch(Exception e) {
>          e.printStackTrace();
>          }
>       } //end method openConnection()
> </code>
> 
> 4. a destroy() method that nulls the DataSource:
> <code>
>    public void destroy() {
>    ds = null;
>    }
> </code>
> 
> <remarks>
> -the conn.close() is called in the methods that call
> openConnection().
> -I'm thinking of doing an 'include' for the
> openConnection method, so I
> don't have the code for the same method sitting in
> multiple classes.
> Would that be a good idea? (maintainability, yes but
> in terms of
> overhead?)
> </remarks>
> 
> Would this be the 'leanest' scenario for a database
> connection?
> thanks again,
> Luke
> 
> -- 
> ========================
> Luke (Terry) Vanderfluit 
> Mobile: 0421 276 282     
> ========================
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Any opinions expressed in this E-mail may be those of the individual and not 
necessarily the company. This E-mail and any files transmitted with it are 
confidential and solely for the use of the intended recipient. If you are not the 
intended recipient or the person responsible for delivering to the intended recipient, 
be advised that you have received this E-mail in error and that any use or copying is 
strictly prohibited. If you have received this E-mail in error please notify the 
beCogent postmaster at [EMAIL PROTECTED]
Unless expressly stated, opinions in this email are those of the individual sender and 
not beCogent Ltd. You must take full responsibility for virus checking this email and 
any attachments.
Please note that the content of this email or any of its attachments may contain data 
that falls within the scope of the Data Protection Acts and that you must ensure that 
any handling or processing of such data by you is fully compliant with the terms and 
provisions of the Data Protection Act 1984 and 1998.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to