XJ: Micael K�llman wrote:
> Hello everybody
>
> I want to check the syntax to use when storing my connection pool in the
> ServletContext. I had problems with my singleton pool-object so I decided to
> try this approach mentioned in recent postings.
>
> It works definitely better than my other one, but there are some things that
> make me wonder. At the moment I am doing getAttribute() twice, is that good
> or bad? With this approach I can do everything in local variables in each
> method, but since I really should synchronize the calls for getAttribute()
> anyway I guess I could just as well make the pool a class variable, thereby
> reducing the method calls I have to do. Or what do you think?
>
The cost of a getAttribute() call is roughly the same as a Hashtable.get()
call, because that's the way the attributes are stored in most servlet
engines. It's fast enough that I wouldn't worry about it.
In general, there isn't a need to synchronize around getAttribute() calls,
because all you're doing is grabbing a reference to the existing connection
pool. The place that synchronization is needed in your example is inside the
DbConnectionBroker.getConnection() method, because that is where you are
changing the state of the connection broker object -- you don't want it to
allocate the same connection to two threads at the same time. Once the
connection has been allocated to you, thread safety is not an issue -- the
thread running your current request will be the only one using that particular
connection until you give it back with the freeConnection() call.
Regarding class variables, you could certainly put the connection pool there,
if this was the *only* servlet in your application that needed access to it.
However, if you need to share the same connection pool between multiple
servlets (or JSP pages), storing it in the servlet context is a useful
technique.
>
> This is what I do right now:
>
> public class SearchServlet extends HttpServlet {
>
> public void init (ServletConfig config) throws ServletException {
> super.init(config);
>
> DbConnectionBroker deebs = (DbConnectionBroker)
> getServletContext().getAttribute("cons");
> if(deebs == null){
>
> // do the driver stuff
>
> deebs = new
> DbConnectionBroker(dbD,dbS,dbL,dbP,minC,maxC,logF,maxCT);
> getServletContext().setAttribute("cons", deebs);
> }
> }
>
NOTE: If this is the only servlet that can create a connection pool and stash
it in the servlet context, then no synchronization is required here -- the
servlet engine guarantees that it will only call init() once. If you have code
like this in multiple servlets, however, it is possible that two servlets will
simultaneously try to create a connection pool and stash it -- the second one
will be there, and the first one will disappear. To avoid this, you could
synchronize on some global static object, or move the setup logic to a special
startup servlet that is started when the servlet engine is executed.
For symmetry, you might also want to add a destroy() method to this servlet
that removes the connection pool from the servlet context, and gracefully
closes all of its connections.
>
> public void doPost (HttpServletRequest req, HttpServletResponse res)
> throws ServletException, IOException {
>
> DbConnectionBroker myBroker = (DbConnectionBroker)
> getServletContext().getAttribute("cons");
> Connection myCon = myBroker.getConnection();
>
> // do the database stuff
>
> myBroker.freeConnection(myCon);
>
> // do the output stuff
> }
> }
>
This is a real typical usage pattern. You will see very similar patterns if
you look at the insides of an EJB server, or a database management system, an
operating system, or many other apps where you need temporarily exclusive
access to shared resources in a multithreaded environment.
The only thing to be really careful about is to ensure that there is absolutely
no path through your servlet that returns without reeing the connection first
(even if your servlet throws an exception). Some connection brokers have
timeout logic that attempt to release a connection that has been allocated for
too long (in an attempt to deal with the "I forgot to free" problem), but
that's going to leave a connection tied up for some period of time, instead of
being available to other users.
>
> I welcome all comments.
>
> Thankful for any help,
> /Micael
>
> Micael K�llman [EMAIL PROTECTED] 018-167709
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
