Here is my input on this interesting topic.
> * some people say, it's best practice to put 1 connection
> into 1 user's http
> session and use it for all requests of that user
This only works if you don't have a lot of users concurrently, say a small intranet
application, that doesn't care scalibility. The reason is database connection can't
be serialized for sure and connection in http session can't be replicated across your
web server farm. Hence each user in a session requires to use the same machine in
your web farm. This could be terrible if you intend to serve thousands of users
concurrently. Secondly database licensing is an issue. Some database vendors charge
you by concurrent opened connection. If your site has a thousand users concurrently,
you will need to purchase a thousand licenses (That is the thing scares me most).
> * other people say it's best practice to use a connection for
> every request.
> (and if more than one methods are involved, the connection
> should be given
> as a method parameter)
>
I would rather use this per-requset approach. Only open a connection whenever a
request comes in and needs database access. I can't think of a reason why passing
around connection as parameter is a bad idea as long as it is in the same request.
> * again other people argue that they don't care at all about reusing
> connection, they just open and close them when they need/want to
I would not like this idea since opening a database connection is expensive unless
there is a connection pooling mechanism in place.
Conrad
