Re: JDBC Connection State Management with SQL Exceptions (esp Postgresql)
От | AV |
---|---|
Тема | Re: JDBC Connection State Management with SQL Exceptions (esp Postgresql) |
Дата | |
Msg-id | DizY6.9880$Xi3.527250@weber.videotron.net обсуждение исходный текст |
Ответ на | Re: JDBC Connection State Management with SQL Exceptions (esp Postgresql) (Joseph Weinstein <joe@bea.com>) |
Список | pgsql-hackers |
"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++) { PreparedStatementnew_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 > 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. ......
В списке pgsql-hackers по дате отправления: