I think it makes sense if you have a transaction that covers multiple page
requests, and don't want to implement a TX.
One alternative is to actually back your system by objects, and then tell
them when to serialize to the db. One issue with that, is it doesn't fit
the web paradigm very well. But this really depends on your application.
For example: a shopping cart only needs to save to the db when the entire
transaction is completed, so backing with objects fits well; an HR /
self-serve employee system would either need to track clients or commit on
each page.
For speed, it is WAY too bad that Oracle can't promote it's multiple session
per connection support into JDBC. In C I can open multiple connections to
the db, and then create multiple user sessions inside of the connection, so
I don't have to deal with the big hit of created the db connection, just the
smaller hit of authing a user on it.
For commercial databases there is no monetary reason to choose between
pools/user connections as they catch you for the max $ either way. The only
reasons are techincal, such as: speed, manageability, session restart etc...
Thor HW
----- Original Message -----
From: Kevin Jones <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 10, 1999 3:22 PM
Subject: Re: Further on Session problems with Java Servlet Programming
Book...
> >>Huh? that statement makes no sense. How does that apply to connections
to
> a database?
>
> The problem Tim is trying to address is valid, and his statement does make
> sense (at least to me). When call DriverManager.getConnection() you can
pass
> a username and a password, connection pooling (more or less) forces you to
> create a set of connections with one username and password (the 'dummy
user'
> Tim refers to). If, for whatever reason, you want different users to log
> onto the database individually then you have to associate the database
> connection with that user - and sessions is one way to do this. Maybe not
a
> great idea, but you have to take into account things like - the number of
> users the system will have and how expensive it would be to re-open the
> database connection at each page boundary,
>
> Kevin
>
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of jon *
> Sent: 10 August 1999 22:54
> To: [EMAIL PROTECTED]
> Subject: Re: Further on Session problems with Java Servlet Programming
> Book...
>
>
> > Yes, I know I could do things with connection pooling, but I want
> different
> > users logged in as their real user ids, not using a dummy user everyone
> > uses.
>
> Huh? that statement makes no sense. How does that apply to connections to
a
> database? I vote that it is a really really bad idea to store connections
to
> a database in a session object.
>
> > Is it a good idea to tie a cookie with a life time of -1, set to the
> session
> > id and when the browser process is terminated (no ambiguity!), the
session
> > associated with the cookie would be invalidated?
>
> I would vote no on this one because for security reasons, you cannot count
> on the "browser" to actually honor that criteria. Also there was something
> fixed in the 1.0.1 development version of apache jserv regarding setting
> cookies to.
>
>
<http://www.working-dogs.com/cvsweb/index.cgi/jserv/src/java/org/apache/jser
> v/JServUtils.java?rev=1.11&content-type=text/x-cvsweb-markup>
>
> -jon
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
