From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat thread pool question
So we have a Tomcat, which somehow has a "pool of database
connections" ready to be lent to webapps.
In this particular case, the db connection pool is managed by Hibernate, not
Tomcat. More typical usage would have Tomcat managing the pool, but it
wouldn't make any difference for this problem.
And we have a webapp capable of borrowing one of the
connections from the pool to do something with it, the
understanding being that when it's done, it gives it
back to the pool.
That's the standard model, but this app design isn't using it. Instead, the
connections are not returned to the pool until the client says it's ok to do so.
- Tomcat receives the request # 2, and passes it to the
same / a different thread. Say it is the same (how that
works I don't know, question below).
Unlikely to be the same, but it doesn't matter.
- the thread somehow re-uses the same db connection which
was borrowed before. How ? was it saved somewhere and can
this thread get the same one back ?
One presumes the webapp stored the connection somewhere retrievable, although
the OP provided no actual evidence of that. It coule be stored in the Session,
or kept in a completely separate active connection structure managed by the
webapp.
- Client issues HTTP request # 3, which is a signal for the webapp to
return the db connection to the pool
Not just return the db connection, but also commit the db updates.
- Tomcat receives the request # 3, and passes it to the same / a
different thread. Say it is the same (how that works I don't know).
Doesn't matter if it's the same thread or not.
Now my question is : considering this is HTTP, where each request is
supposedly independent from previous and following ones, can a scheme
like the above possibly work ?
Yes, because each client can be identified by a session identifier or some
other cookie. However, unless the client is very well controlled and extremely
robust, this design abdicates responsibility for management of server resources
(the db connections) and delegated that to the client, an extremely poor design
choice.
Is it one particular thread which holds this borrowed db
connection, and is request # 2 necessarily processed by
the same thread as request # 1 ?
Highly unlikely.
Where is the borrowed connection stored between the requests ?
Could be in the Session object associated with the client, or some
webapp-managed structure.
Am I right in thinking that for such a scheme to work, even
with well-behaved clients, the borrowed db connection would
need to be saved somewhere independent of a Tomcat thread,
but dependent on some kind of client "session", so that any
thread could pick it up where another one or itself left it
between transactions of that same client ?
Correct; it's only a minor - albeit dangerous - variation on the frequently
used shopping cart seen on many web sites.
