Thank you for the comments, I really will take this into the consideration, while structuring the thing. I would like to make comments on the whole still so please see intermixed :
> -----Original Message----- > From: Ralph Einfeldt [mailto:ralph.einfeldt@;uptime-isc.de] > Sent: 31. október 2002 08:58 > To: Tomcat Users List > Subject: RE: JDBC / ThreadLocal pattern. > > > I don't like this approach for connections in a web > server. Allright... But I would like to point out there are some problems with the usual approach. > > If the connection is available for more than one request > depends on the way the container handles threads. If each > request is a new Thread you will win nothing. > Instead you will loose performace as each request > would create a new connection to the database. > Yes that is true, there for we've thought of a way to have the ThreadLocal get its connection from a pool. > Even if the threads are recycled (If the servlet engine > supports a ThreadPool and is configured to use it), you > don't have control about which request gets which thread, > so I don't see how you will use this to lazy load > resultsets. In this case you also have no control when the > threads are killed. (It's up to the servlet engine) > Well, the connection will not close unless the thread dies. The resultset would use the same connection as it was originated with, but not another one in another thread. It's true the thread might die if it's been used to serve more than some (specific) amount of request, there for I don't know if connection will be alive on my next request ? Good point. > If you don't need database access in every request (which > is quite typical if you use tomcat standlone) the situation > even gets worse. In the long term every thread in the pool > will have a connection (Each time a request with database > access that is assigned to a thread that has no connection > a connection has to be created for that thread.) Yes, many connections, some databases don't mind, some do mind. > > Many drivers have problems with connections that are not > explicitly closed so you would have to make shure that > close() is called whenever a thread is killed. Hmm ok, I did not know that. > > It's also not a good idea to rely on the garbage collector > to close connections as you don't have control when the gc > is run. > > It's very likely that you keep much more connections open > than you actually need, you might even run out of > connections if you hit the database limit. Still you should be able to have a fixed limit, for example tomcat is set up default to have 75 threads, this means that if you have one connection per thread, it would be something like yes, 75 connections (which is probably way to much). > > With a connection pool you have a much better control > about the amount of open connections. > We've been using connection pools, and it's been very good, we're mainly looking for more efficient ways of dealing with JDBC connections etc. I thought this was a good idea when it was first presented to me, but then I've had all kinds of different ideas if its good or bad. Ok, thanx again for those comments. -reynir > Ralph Einfeldt > Uptime Internet Solution Center GmbH > Hamburg, Germany > Hosting, Content Management, Java Consulting http://www.uptime-isc.de > > > -----Original Message----- > > From: Reynir Hübner [mailto:reynir@;hugsmidjan.is] > > Sent: Wednesday, October 30, 2002 8:06 PM > > To: Tomcat Users List > > Subject: JDBC / ThreadLocal pattern. > > > > In (very) short: the idea here is to have one > > jdbc-connection for each thread, instead of a pool with connections. > > > > 1. I will never have to worrie about not returning > > connections anymore, as they will always be garbage collected > > as soon as the thread is dead. > > 2. The connection will be available for more than one > > request so I can lazy load resultsets. > > 3. This might make transaction-service implementation easyer > > 4. many other great things.... > > > > -- > To unsubscribe, e-mail: > <mailto:tomcat-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
