> 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. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
