Message-ID: <3B33A239.9B4D884D@bea.com>
Date: Fri, 22 Jun 2001 12:53:29 -0700
From: Joseph Weinstein <joe@bea.com>
MIME-Version: 1.0
To: AV <avek_nospam_@videotron.ca>
Subject: Re: JDBC Connection State Management with SQL Exceptions (esp  
	Postgresql)
References: <F4rY6.1017$CF3.129497@newsread2.prod.itd.earthlink.net>
	<3B3277C6.4C9BCA9@bea.com>
	<DizY6.9880$Xi3.527250@weber.videotron.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: BEA SYSTEMS Inc
Lines: 70
To: pgsql-hackers@postgresql.org.pgsql-general@postgresql.org


AV wrote:
> 
> "Joseph Weinstein" <joe@bea.com> wrote in message
> news:3B3277C6.4C9BCA9@bea.com...
> >
> > John Moore wrote:
> .....
> > > I am doing transactional work, with multiple statements and then a
> commit().
> > > I am also doing my own connection pooling, so it is important that I be
> able
> > > to reliably re-use connections.
> >
> > Hi. There is a lot of state that can be left with a connection, and a good
> > pooling system should do a bunch of cleanup on the connection when it is
> > returned to the pool, so it will be ready for the next user. This would
> include
> > closing all statements and result sets that the previous user may have
> created
> > but not closed.
> 
> What about PreparedConnection pooling?
> What is your oppinion on the following  code
> [design] for such caching within a connection :
> ( getUsedPstmts() is imaginary method of imaginary
> MyConnection interface )
> 
> public void returnConnection (Connection con) {
>    Connection local_con = con;
>    con = null;
>   PreparedStatement [] used_pstmt = (MyConnection) local_con.getUsedPstmts()
>   for (int i =0 ; i < used_con.length ; i++) {
>         PreparedStatement new_pstmt = used_con[i];
>         used_con[i] = null;
>        cached_pstmt_HashMap.put( new_pstmt.getSql(),  new_pstmt );
>   }
> ... some other cleaning steps....
> ...set connection as available...
> }
> 
> AlexV

Hi Alex. I think I understand this... The basis of caching/re-using a PreparedStatment
is via the SQL used to create it, but I see no actual statement-level cleanup here.
You should be clearing any warnings the statement may have accrued. Another example
is that you should do something to cover the possibility some user code called setMaxRows(1)
on the statement. You don't want this condition to remain and silently truncate the results
of any subsequent user... This code also doesn't allow for multiple statements with the
same SQL. There will be some 'utility' statements that might be used at several levels
in a user's stack, and you want to allow for caching multiple identical statements *and*
making sure that no two methods in the same caller stack get the *same* statement,
even if it is the same SQL.

Joe


> 
> > This is crucial because you don't want retained references
> > to these objects to allow a 'previous user' to affect anything the next
> user
> > does. ......

-- 

PS: Folks: BEA WebLogic is expanding rapidly, with both entry and advanced positions
for people who want to work with Java, XML, SOAP and E-Commerce infrastructure products.
We have jobs at Nashua NH, Liberty Corner NJ, San Francisco and San Jose CA.
Send resumes to joe@bea.com