Return-Path: 
 <commons-user-return-5451-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 69220 invoked from network); 29 Oct 2003 04:30:19 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 29 Oct 2003 04:30:19 -0000
Received: (qmail 60189 invoked by uid 500); 29 Oct 2003 04:29:55 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 60174 invoked by uid 500); 29 Oct 2003 04:29:55 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-user-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 60149 invoked from network); 29 Oct 2003 04:29:55 -0000
Received: from unknown (HELO conan.f2.com.au) (203.26.51.167)
  by daedalus.apache.org with SMTP; 29 Oct 2003 04:29:55 -0000
Received: from sydmsg1.int.f2.com.au (h-172.31.139.16 [172.31.139.16] (may be
 forged))
	by conan.f2.com.au (8.12.10/8.12.10) with ESMTP id h9T4U3w1002638
	for <commons-user@jakarta.apache.org>; Wed, 29 Oct 2003 15:30:04 +1100
Received: by sydmsg1.int.f2.com.au with Internet Mail Service (5.5.2657.72)
	id <VNZ1W0X1>; Wed, 29 Oct 2003 15:29:56 +1100
Message-ID: <9BAE99905FCF684D91F63E1439475FBA0F6A6513@sydmsg1.int.f2.com.au>
From: Brett Porter <bporter@f2network.com.au>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: RE: DBCP : some questions.
Date: Wed, 29 Oct 2003 15:29:56 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39DD5.4E4426F0"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

------_=_NextPart_001_01C39DD5.4E4426F0
Content-Type: text/plain

> For transaction support previously I was turning the 
> AutoCommit off and then the connection is put in the session 
> and forwarded to next JSP/servlet and closed the connection 
> after use. Is it the right method. Or there is any better method.

And if the next page is never requested, you leak connections. Bad idea.

You should isolate the transaction to a small period of time to avoid
locking the database. If you have potential for concurrent accesses to the
database, you will need to "dirty check" your information in the second
request.

Ie.

Request 1: get connection, select information, close connection. Pass
information to request 2.
Request 2: get connection, check information hasn't changed (can use
timestamps for this), update information with that passed from request 1,
close connection.

> 
> In DBCP example using JNDI this code  is used to get 
> connection. Context initContext = new InitialContext(); 
> Context envContext  = (Context)initContext.lookup("java:/comp/env");
> DataSource ds = (DataSource)envContext.lookup("jdbc/Test");
> Connection conn = ds.getConnection();
> 
> putting this code in every page,servlet and bean is not a 
> good idea(lot of typing and importing all class files). Any 
> better method for doing it.

You should abstract it into a separate class.

- Brett

------_=_NextPart_001_01C39DD5.4E4426F0--