Hi Randy,
In building my own applications I usually make a compromise
by only storing information applicable to the logical "session"
in the actual "session", including such things as user's id.
If the information is to persist longer than the logical "session"
then I put that information in EJBs. You would never want
to use in-memory session replication as a long-term persistent
store of information; I would say that it is not optimized for
that case. The case that it handles best is the case where you
want information, like the session id or the contents of a users
shopping basket, to be maintained while they are using the system
and then it can be released.
For instance, in internal WebLogic application efforts we have used
sessions to keep track of current session usage and identity but
use an EJB based profile for permanent information and aggregated
usage patterns.
Sam
> Sam,
>
> I've heard the same concern Laird expressed that you want to keep the
> amount of information you store on the session limited (e.g. just put
> the user's id in the session and the rest of the state gets written to
> the database)
>
> Is your feeling that this isn't necessary if using WebLogic and
> in-memory session replication?
>
> Randy
===========================================================================
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
