> > * 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
