One thing you could do is call getConnection() twice and then System.out.println( con1 == con2 )
Then email him the 'false' response. He can't deny that. On Aug 4, 12:42 am, Arulin of ACBL <[email protected]> wrote: > Thankyou all, > > The getConnection() was our senior level Java developer's idea... > Kinda figured JDBCTemplete would buck that but no way I was going to > prove it to him. Seriously, no one here trust me (alittle HADD) so > I'll have to run this through him, at least I have this information to > back me up. > > After posting here and at Spring Source , I've come to serval flaws in > the system. > > First of all , I hope our senior developer will listen. Secondly, the > getConnection should be stripped, that has caused enough headaches. We > are using default setting in org.apache.commons.dbcp.BasicDataSource, > which has us hosed on thread handling since the DataSource controls > and watches the threads so I have found out. Then if that's not it, > seems our Websphere admin will have to fess up and do some re- > configuring on the app server. There is a possible flaw in the > transaction configure file but likely a BasicDataSource issue. So I'll > try and get that looked into thanks again > > On Aug 1, 9:48 pm, Keith Haber <[email protected]> wrote: > > > > > Agreed. Personally I'd get rid of the isJDBCConnectionClosed() method > > entirely, for a few reasons. > > > First, as Mike and Mark say, each call to getDataSource().getConnection > > () is grabbing a new connection from the DataSource, so it looks like > > you're leaving a lot of connections open that JdbcTemplate would > > normally close/free up for you. It's not safe to call getConnection() > > like a regular bean property getter! That's probably the source of > > your resource leak, if it's not a problem with the WebSphere config. > > > Second, if you have a connection pool under the covers, your > > connections aren't really getting closed anyway. After all, the whole > > point of connection pooling is to reuse open connections to improve > > performance, so you actually want them to stay open! > > > Third (and this gets into my personal design preferences so take it > > with a grain of salt), the DAO pattern's purpose is to encapsulate and > > hide the details of persistence from the rest of your application. If > > you do it right, you should be able to replace your DAO implementation > > with one that saves and retrieves objects using a web service, a > > serialized file, a java.util.HashMap, or something else other than a > > SQL database, and the rest of your app shouldn't care. The > > isJDBCConnectionClosed() method exposes your implementation in a way > > that takes away that flexibility. Consider carefully why anything > > outside your DAO class should be concerned with JDBC Connections, even > > if you don't think you need that flexibility right now. My experience > > has been that you pretty much never want to expose that implementation > > detail. Not saying it's never a good idea, but there should be a good > > reason to do it. > > > Hope this helps. Good luck! > > Keith > > > On Aug 1, 11:33 am, Rakesh <[email protected]> wrote: > > > > exacttly - the whole point of JdbcTemplate is that you do not need to > > > do any connection management. > > > > Spring 101. > > > > R > > > > On Sat, Aug 1, 2009 at 8:53 AM, Colin B-S<[email protected]> > > > wrote: > > > > > Keith is right, this is more likely to be your configuration in > > > > WebSphere. > > > > Also the JDBCTemplate will close your connection for you. If the > > > > connection is configured as a pooled connection then the close() just > > > > returns it to the pool. > > > > > Colin. > > > > > On Jul 31, 3:14 pm, Arulin of ACBL <[email protected]> wrote: > > > >> Hello Java Posse, > > > > >> Our system Admin is tearing his hair out over JDBCtemplete, it is not > > > >> closing threads that it opens between Websphere App Server and DB2, we > > > >> are on an AS400/AIX based system. The system gets over 1000 threads > > > >> that are just sitting there, I've searched the net for possible > > > >> solutions with little luck. Is there a way of making the DAO close the > > > >> threads safely so that JDBCTemplete isn't half doing it's job? > > > > >> I'll toss an example of our current the DAO... > > > >> *************************************************************************** > > > >> **** > > > >> package learntoplaybridge.jdbc.dao; > > > > >> import java.sql.SQLException; > > > >> import java.util.List; > > > > >> import org.acbl.utility.Util; > > > >> import org.apache.log4j.Logger; > > > >> import org.springframework.jdbc.core.RowMapperResultReader; > > > > >> public class TableJdbcDao extends AbstractJdbcDao { > > > >> private String sql; > > > > >> private Object[] params; > > > > >> private String db = (Util.getServer().equals("PROD")) ? > > > >> "file.table" > > > >> : "test.table"; > > > > >> public Table lookUpPrices(){ > > > >> sql = "select MNEW$, MMEM$1 from {db} order by MYYMM > > > >> desc"; > > > >> sql = Util.replaceSubString(sql, "{db}", db); > > > >> List l = getJdbcTemplate().query(sql, params, new > > > >> RowMapperResultReader(new MEP022RowMapper())); > > > >> return (l.size() > 0)? (MEP022)l.get(0) : null; > > > >> } > > > > >> // Ensuring the data ccnnection is closed > > > >> // This crashes each time we run it. > > > >> public void isJDBCConnectionClosed(){ > > > >> try { > > > >> if(this.getDataSource().getConnection() != null && this.getDataSource > > > >> ().getConnection().isClosed() != false) // Here dao is the Object > > > >> reference > > > >> { > > > >> > > > >> this.getDataSource().getConnection().close(); > > > >> } > > > >> } catch (SQLException e) { > > > >> // TODO Auto-generated catch block > > > >> e.printStackTrace(); > > > >> } > > > >> } > > > > >> }- Hide quoted text - > > > > >> - Show quoted text -- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
