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);
}
}
> Date: Wed, 17 Sep 2008 09:40:16 -0400
> From: [EMAIL PROTECTED]
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 5.5, JNDI Connection Pooling, Active connections keep
> increasing....
>
> Comments inline ...
>
> Johnny Kewl wrote:
> >
> >> >> So, what exactly does it mean when we say that Tomcat is thread
> >> safe >> for
> >> >> requests.
> >> >> Tomcat creates a new thread for each request, so somehow my static
> >> >> methods
> >> >> are then thread safe (incdirectly, since it is managed by Tomcat).
> >
> > I actually searched all over to try find something for you.... this
> > looks ok
> > http://www.codestyle.org/java/servlets/faq-Threads.shtml
> >
> >
> > But here my un-scientific way of thinking about it...
> >
> > When tomcat sends a thread into your doGet method...
> > All those local variables in that thread are ok...
> As long as you mean variables defined inside of the doGet() method.
> Class instance variables are not cool in servlets.
> >
> > So I think about it as each thread being a lane on a big
> > freeway/highway...
> But objects are not thread local unless they are setup that way
> implementing something like ThreadLocal. Only the references to the
> object are local.
> >
> > So yes you right in a way... Tomcat isnt allowing those local method
> > variables to get mixed up...
> > but the second you decalare a static method or static variable... you
> > had better be sure its thread safe.
> Let's not confuse static methods and static variables. Static variables
> should be avoided unless they are true constants. Static methods on the
> other hand are fine, but need to be careful when those static methods
> interact with object instances that may not be thread safe.
> >
> > What happens to that highway is that all the lanes merge into one, and
> > every car has to go through it...
> Now your are talking about a singleton -- a whole different ball of wax.
> >
> > When you add synchronized... your 30 lane high way becomes a single
> > lane and its one car at a time...
> Still in singleton land with the one lane analogy. Syncs do add a huge
> performance penalty though, so even outside of singletons, syncs should
> be avoided as much as possible.
> >
> > You dont want to add synchronized because here you have the TC guys
> > gone thru all the hassle of making sure you can have a 30 lane
> > highway... and you bang it into one lane.... so new is better because
> > each lane gets its own engine... and java is pretty damn good at
> > garbage collecting, that little bit of memory is a blip on the radar
> > screen...
> >
> > You got to really know what your code is doing when its static... you
> > got to know its thread safe, and it can be really hard to see that 30
> > car pile up coming on the highway ;)
> >
> > My way of thinking about this stuff..... mad science - chapter 1 ;)
> Johnny -- You might find the java language reference an interesting
> read. It describes all the rules regarding threading, access, value vs
> reference variables, etc., ...
>
> --David
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
_________________________________________________________________
Discover Bird's Eye View now with Multimap from Live Search
http://clk.atdmt.com/UKM/go/111354026/direct/01/
