Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Message-ID: <3F9F5F34.2030206@apache.org>
Date: Tue, 28 Oct 2003 22:33:24 -0800
From: "Craig R. McClanahan" <craigmcc@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: DBCP : some questions.
References: <9BAE99905FCF684D91F63E1439475FBA0F6A6513@sydmsg1.int.f2.com.au>
In-Reply-To: <9BAE99905FCF684D91F63E1439475FBA0F6A6513@sydmsg1.int.f2.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Brett Porter wrote:

>>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.
>
>  
>
Or if the session expires.  If you want your application to be scalable, 
you should never ever ever ever keep a connection from a connection pool 
across requests.  In the case of something like a wizard dialog, then, 
it's fine to allocate read-only connections for each page of the wizard 
(and release them before returning the response) but you'll want to 
accumulate all the state information necessary to update things until 
the user presses the "Finish" (or whatever) button.

>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.
>
>  
>
Yep.  That kind of thing happens too.


>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
>
>  
>
Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org