----- Original Message -----
From: "sinoea kaabi" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Wednesday, September 17, 2008 4:48 PM
Subject: RE: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
increasing....
This question about static variables seems a bit deeper than I
thought, the more I think about it the more confused I get.
I could accept the fact that we should create new objects of Dao's,
but for getting a datasource or connection it should make sense
to have a utility class with static methods.
Collection<Branch> branches = new BranchDao().loadBranches(
new DBUtil().getDataSource(), // This feels crap, I'd rather use
DBUtil.getDataSource() (without new)
1);
DBUtil should have static methods for retrieving a datasource or a
connection,
creating a new DBUtil for each request does not feel right.
Well, you say that static methods don't necessarliy improve performance
in the long run, but why does the code at the bottom work for others.
And what is a thread-safe object:
An object whose state cannot be modified
So is a connection a thread-safe object or not?
It looks like you can modify its state (closing and opening it)
Below is a new connection object created, it is therefore
not a static class variable, only the method is static.
This means that the method should be thread safe, since a new connection
object is created for each thread.
public static Connection getConnection(){
try {
Context context =(Context) new
InitialContext().lookup("java:comp/env");
DataSource dataSource = (DataSource) context.lookup("jdbc/FooBar");
Connection connection = dataSource.getConnection();
return connection;
} catch (NamingException namingException) {
log.fatal(namingException);
throw new RuntimeException(namingException);
} catch (SQLException sqlException) {
log.fatal(sqlException);
throw new RuntimeException(sqlException);
}
}
sinoea, of course you can... that looks thread safe... but what I'm trying
to do, is just make it bullet proof...
You leaking connections, we dont know why... so idea is to try take any
threading issues out of the equation...
Then you run it, it works... you play with the code...add your routines
back... find whats causing it...
.... and then you going to tell us why it was leaking.... thats what we
dying to know;)
You wont be the first person that stared at a piece of code for 2 days and
not seen the threading issue...
It can be really hard to spot...
If a person gives you a class and says... this is NOT thread safe... what
you going to do with it?
Thats the thing I'm showing you...
David right, I'm no teacher... but I've done it a million times... send me
your code, I'll find the problem for you...
---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
