Hey out there,
using JdbcTemplate in Websphere caused some connection pooling issues
for us, too. What turned out to be the problem was us using the
DataSourceTransactioManager instead of the one dedicated to WebSphere.
So in cases of polling problems check if you use the right one :)
Regards Ollie
On 3 Aug., 16:42, Arulin of ACBL <arutheunic...@gmail.com> 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 <kjha...@gmail.com> 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 <rakesh.mailgro...@gmail.com> 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<cbrodie.sm...@googlemail.com>
> > > 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 <arutheunic...@gmail.com> 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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
