Craig,
I really appreciate your inputs. I fully agree with your comments as
to not storing resultsets in session beans. I was just trying to understand
how sessionbeans are made persistent,Infact I was planning to use some other
Java Object similar to the CachedRowSet from JavaSoft and store that in my
session bean. I am happy that thats the recommended approach.
One more question: What would i have to do in order to destroy a
session bean in the middle of a session. That sounds like an Oxymoron
doesn't it.
Thanks for your time
Sanjay
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 05, 2000 3:57 PM
To: Radhakrishnan, Sanjay (c)
Cc: [EMAIL PROTECTED]
Subject: Re: Members of SessionBeans in JSP
"Radhakrishnan, Sanjay (c)" wrote:
> Accoring to my understanding Data Members of SessionBeans in JSP should be
> serializable. So ResultSet and Connection Objects cannot be Members of
> Session Beans. Am i right in Saying that?
>
Per the 2.2 servlet spec, the objects you store in a session bean must be
serializable only if your application is marked distributable (i.e. it can
run in
more than one JVM at the same time). Otherwise, it is optional.
>
> Yet when i include resultset objects as members of session beans, the
> resultset(inside a sessionbean) created by one page are accessible thru
> another page(Both pages make use of the Bean tag). I am assuming that
> Jrun(which i use) employs serialization to achieve this.
>
Serialization is not required for this -- instead, the session data objects
are
shared between all the JSP pages and servlets in the application. It is the
same
ResultSet instance, so no copying is required.
>
> How is that possible if Resultsets are not serializable.
>
> Appreciate your inputs
>
There is a different reason, though, that I would recommend against storing
ResultSets in user sessions even though it works. It has to to with the
scalability of your application.
Storing the result set in the session implies that it is going to remain
there
across requests from the user (otherwise you might as well store it as a
request
attribute). To be usable in a subsequent request, the ResultSet must remain
open,
which implies that the corresponding Statement that created it must remain
open,
which implies that the database connection which created this Statement must
remain
allocated to this user. (You can get away with sharing a connection across
multiple users in a read only environment, but transactional COMMIT and
ROLLBACK
commands will cause interference if you are updating things.) This means
that you
need an available connection for each simultaneous user, even if that user
just
took off for lunch.
The recommended approach to scalability is to use a connection pool, and
(within a
single request), always give back the connection you were using before you
return
the result page to the user. The implication for this discussion is that
you
should copy the result data you need to keep into some Java object of your
own
(maybe a Vector full of beans that contain a bean per row or something like
that),
so that you can close the result set (and the associated statement, and
release the
connection) before returning the page.
Using this approach, the number of database connections you have only limits
the
number of simultaneous requests you can handle, instead of the number of
users
currently logged on to your applicaiton. Depending on how active the users
are,
these two numbers can be *substantially* different.
>
> Sanjay
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
