struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <>
Subject RE: BEA Claims about Struts on Weblogic
Date Fri, 22 Sep 2000 15:31:28 GMT
> -----Original Message-----
> From: Jean-Baptiste Nizet []
> Sent: September 22, 2000 11:07 AM
> To:
> Subject: Re: BEA Claims about Struts on Weblogic
> Steve Wilkinson wrote:
> > <deleted>
> > FYI, another thing about Weblogic..
> > When you use Beans in your JSP with session scope, Weblogic 
> copies the contents of
> > the bean into memory and re-instanciates your bean and 
> copies the values back into
> > it.  At least, this was the case in 4.5.1.  If you want to 
> test it, put a comment
> > or log message in the constructor of your bean and check it 
> out.  In addition, in
> > 4.5.1, the <jsp:include...> would not even compile if you 
> had a flush=true in the
> > tag.  They have their own problems.
> >
> Not sure this is the right place to ask, but since the issue 
> is raised...
> Does Weblogic provide a persistent, shared, session 
> mechanism? If this is the case,
> perhaps the problem you mention comes from this mechanism: 
> the session is stored in a
> database or serialized in a file, and then reloaded afterwards.
> What does Tomcat provide in that area? Is it possible to 
> share sessions between two
> different web servers? Is it possible to have automatic 
> fail-over for the sessions? Is
> it possible to load-balance between web servers?
> JB.

Yes, WebLogic can persist sessions to share them between different machines.
They can persist to JDBC, to a shared filesystem, or the preferred solution
(much faster) is to persist in memory to a secondary (every cluster member
cn have a secondary in this respect). In the latter case, requests always go
back to the primary, and if that is down, get sent to the secondary.
Anything in the Session that is to be persisted must be serializable, for
obvious reasons. This means for example that if you store an EJB remote ref,
you should also store a handle (which unlike the ref is serializable) to it,
so you can recreate it if you come back in another request and find that
your ref is now null.

Resin can also now persist sessions. I haven't played with the feature to
see how well it works, but will be doing so, since for the time being its
JSP/Servlet implementation is much better than WebLogic's...

View raw message