How about just returning the connection to the pool as soon as the servlet
is finished with the database? The approach I took was to have the pool
create a new connection if needed up to some maximum (determined by the
database or performance limits), then make the servlets always let go of a
connection as quickly as they can, so the pool can hand it to another
servlet. I've found that with only 3 or 4 connections you can get many times
that many users, as the probability of more than 3 or 4 asking for a
connection at the same instant isn't too high.
I also do the "wait until there is one" part, but with a limit on that too
(e.g. wait no more than X seconds).
I'm interested in how other people are tackling this, as the basic
connection pool examples seem to run out of steam in the real world
sometimes... at the same time I don't want to get too complex.
Mike
http://www.javacorporate.com
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's
> Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
> Srinivasan S (Systems Engineering Group)
> Sent: Friday, August 20, 1999 11:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: very much a newbie design issue...
>
>
> Exactly this is what i am thinking for, all the example in
> the books and
> articles are static meaning only 20 or 30 connections are created just
> imagine a html form consists of nearly 30 columns and the
> user fills those
> columns after he press the submit button being 31st client in
> the pool he
> will get an error, instead this client shall be made wait till a
> connection is free in this pool. My question is that i am running a
> thread in my code which checks for any free connection and
> wait if not.
> Another method provides connection to the user, if i call the
> connection
> method from another code what will happen if no connection available.
> for example:
>
> Connectionpool.java
>
> public void run()
> {
> while(true)
> {
> try
> {
> synchronized(con)
> {
> Connection con1 = (Connection)pool.pop();
> if con1 == null
> thread.wait();
> }
> }
>
> }
> }
>
> Public Connection getConnection
> {
> Connection c1 = (Connection)pool.pop();
> }
>
> Public void releaseConnection
> {
> thread.notify();
>
> }
>
> Another method named Client.java
> ================================
>
> Connectionpool cp = new Connectionpool()
> cp.getConenction();
>
> I need to know what exactly will happen now if no connection
> is available
> in the pool wil this cp.getConnection will return a
> Connection object or
> not??
>
> Folks any comments/suggestions to this one.
>
> Thanks
> Srini
>
>
> #-------------------------------------------------------------
> ----------#
> #
> #
> # "ARISE AWAKE and stop not till the GOAL is
> reached" #
> #
> #
> # [EMAIL PROTECTED]
> #
>
> #-------------------------------------------------------------
> ----------#
>
> On Fri, 20 Aug 1999, peter greaves wrote:
>
> > hi
> >
> > i've have my first simple JDBC servlet working and it's ok
> but it won't
> > scale. i read about connection pooling and looked at the
> global broker
> > stuff, but i wondered if i could use a schema like this to
> make the whole
> > process more scalable. any comments gratefully received!!!!
> >
> > 1. Use a Connection Manager and event model
> >
> > Seems to me that servlet incurs much of its overhead if it
> needs to make a
> > connection to its query target each time it is called. It
> is better to
> > create a single static Connection Manager object (created
> in the init()
> > method of the servlet when the web server's Servlet Manager
> starts up) which
> > establishes a pool of connections and allocates them on
> demand to worker
> > threads (see below) as "real" user requests come in. There
> are a number of
> > downloadable Connection managers classes which can be used
> for this purpose.
> > Here's a bit of a thinking-out-loud about how it would work.
> >
> > The Connection manager's job is to maintain a free pool,
> keep track of
> > allocated conenctions, and maybe expand the pool if
> necessary using some
> > %age free algorithm, report errors in the connection layer etc. An
> > event-based model seems useful for connecting the
> Connection Manager (as a
> > server) to its worker threads (the clients). When the
> servlet's destroy()
> > method is called, a servletClosing event should be fired
> which will cause
> > the Connection Manager to repeatedly try to close its free
> connections, and
> > not respond to "connectionRequested" events. This will
> mean that existing
> > queries will be honoured, but no new ones can be created.
> >
> > 2. Use Java Threading and separate worker threads for
> processing queries.
> >
> > The servlet class should maybe just create a new worker
> thread to handle
> > each request and then go back to listening for requests.
> The worker should
> > fire an "connectionRequested" event, which the ConnectionManager is
> > listening for. The Connection manager will reply with a
> Connection object
> > The worker will run the query, and fire a "connectionFree"
> event (which
> > causes the Connection manager to return the connection to
> the pool), deposit
> > the result set wrapped in (probably) HTML on a stack and fire a
> > readytoShipToClient event for which another thread is
> listening - this
> > thread can serve the results back to the client.
> >
> > what do folk think? am i overthreading? :) obv. i want to
> get the design
> > right at the outset. btw, i'm running on Domino R5.
> >
> > peter
> >
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com
> >
> >
> ______________________________________________________________
> _____________
> > 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
> >
>
> ______________________________________________________________
> _____________
> 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
>
___________________________________________________________________________
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
