hi !
to put some oil into the fire: i got the idea of putting a db connection
into the session from the book "Designing Enterprise Applications with the
Java 2 Platform, Enterprise Edition" written by the Sun Enterprise Team
(Rahul Sharma was the author of the specific chapfter)
on page 156, in chapter 6.8 "Guidlines for Connection Management" rahul
wrote: "A JSP page or servlet acquires and holds on to a JDBC connection in
relation to the life cycle of its HTTP session. It can handle multiple HTTP
requests across a single HTTP session from Web clients using the same JDBC
connection"
He did not mention any backdraws of that method.
but one argument brought by some people in this list remains unbeaten: a
user session usually lasts 30 min. within this time it is not unusual for a
mid-sized Web-Site that several hundred people come to that page, which
leads to several hundret concurrent db connections.
my opinion is, that unless you find a way to seach and destroy the inactive
connections, and unless you have an extreme strong and forgiving database
you may get a problem (for example if db hangs because of too much
connections, or license problems and so on)
[not to mention the second argument with the non-serializability of db
connections and the problems with server clusters]
any comments?
any explainations?
joe
keith kwiatek wrote:
* 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).
Agreed with replier..you would NEVER want to do this. If you are not
careful
you can lose the connections which will ultimately crash the database
and/or
the web server. VERY bad design.
Hello,
With regards to the discussion above, and the "tieing of an http session
to a single (or multiple) database connections", a lot of
people downed this idea, BUT...
I actually consider the "one http/db connection" to be a good way for
small/medium intranet type applications to use the
"transaction managment" of the database (ie oracle's "select for update",
two phase commit).
OTHERWISE, HOW would you handle the transaction management ?! If you use
database connection pooling in an http
sessionless environment, how do you handle the dirty read/write situation?
What do you do if an http request fetches data for
"update", but by the time the update is accomplished, the data has already
changed (please don't tell me you you've coded a
"check timestamp" for database rows!)? Or does everyone use optimistic
locking?
OR is this where the powers of EJB state + transaction managment comes in?
Thanks,
Keith
___
Say Bye to Slow Internet!
http://www.home.com/xinbox/signup.html
