"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
