Thanks for the info! Just to summarize for anyone else interested:
These were the bug fixes for sessions in SP2:
Bug 17863 - JRun was not properly keeping track of session information when
the JRun server was shut down. This occurred even if the Use Session
Persistence Engine field in the Web Application Session panel of the JMC
was set to true. Now, if you shut down JRun while a user is still active,
JRun writes the session information to a file. As long as the user keeps
the browser open, JRun restores the original values when it starts up
again. When the field is set to false, all session information is lost.
Bug 21008 - When using a multi-framed application with
session.maxresident=0, the incorrect session data was sometimes being read
under heavy load. This was due to a synchronization problem when reading
data from the database. As part of the fix, JRun now includes a new
optional property:
session.persistence.synchronized=[true | false]
The default is true. If true, then writing to the session provider, all
access should be synchronized. It only becomes active if
session.maxresident=0. If false, the underlying storage provider must be
able to handle multi-threaded writes. The standard JDBCSessionStorage
provider does handle multiple threads writing at the same time (through the
implementation of a pool of PreparedStatements), but this does not mean
that the JDBC driver in use supports multi-threaded access. This setting
should be considered if session.maxresident=0 (immediate session swapping,
such as in a ClusterCats environment) and response times are being impacted
by waiting to write to the underlying storage provider; setting this value
to false may improve response throughput.
These are the bug fixes in SP1:
Bug 18143 - JRun was not ignoring the Authorization header when there are
no session attributes present
Bug 18440 - JRun was setting session tracking cookies even when Use Session
Cookies was set to false.
Bug 18710 - Problems occurred during serialization (for session
persistence), when session attributes were removed from the session, the
session was persisted, and then deserialized, resulting in the loss of some
of the original attributes.
Bug 18723 - Session state could not be saved when storing serializable
objects.
Bug 17780 - Although this bug is listed as fixed, there are known
limitations:
This does not fix the case of naming a Web application the same name as a
service (you cannot use the following names: scheduler, logging, monitor,
license, control, session, authentication, jsp, file, ejb, or jms).
This does not fix the case of naming a servlet the same name as a Web
application service (file, session, authentication, logging, scheduler,
jsp.jikes, jsp, and invoker). These services are loaded as servlets within
the Web application context and referring to them by name will cause JRun
to find them first (instead of a user-written servlet or alias).
On Wednesday, July 11, 2001 4:36 PM, Drew Falkman
[SMTP:[EMAIL PROTECTED]] wrote:
> I think they were minor. There were more session fixes in SP 1. You can
> read about this all here:
>
> http://www.allaire.com/documents/jrun30sp2/relnotes.htm
>
> Drew
> ----- Original Message -----
> From: "Jackie Comeau" <[EMAIL PROTECTED]>
> To: "JRun-Talk" <[EMAIL PROTECTED]>
> Sent: Wednesday, July 11, 2001 1:22 PM
> Subject: RE: Session's getting "mangled" in 2.3.3 or other versions? Your
> experiences?
>
>
> > What were the session issues in 3.0?
> >
> > On Wednesday, July 11, 2001 4:08 PM, Drew Falkman
> [SMTP:[EMAIL PROTECTED]] wrote:
> > > FYI: Service Pack 2 for 3.0 fixed some session issues and 3.1
shouldn't
> have
> > > any either.
> > >
> > > Drew Falkman
> > >
> > > ----- Original Message -----
> > > From: "Nilanjana Chakravarty" <[EMAIL PROTECTED]>
> > > To: "JRun-Talk" <[EMAIL PROTECTED]>
> > > Sent: Friday, June 08, 2001 6:46 PM
> > > Subject: Re: Session's getting "mangled" in 2.3.3 or other versions?
> Your
> > > experiences?
> > >
> > >
> > > > Oh yes!! I have also faced this problem in my application where
> > > > suddenly the sessions go beserk. And I was using JRun 3.0. As
> > > > pointed out, the problem is very rare but serious and in my case
> > > > occured only once. So we gave it up as a freak.
> > > >
> > > > Nila.
> > > >
> > > > --- Lynn Walton <[EMAIL PROTECTED]> wrote:
> > > > > Hi all,
> > > > >
> > > > > I'm still on 2.3.3 build 157 (for Solaris-Sparc). Recently
> > > > > I've been
> > > > > getting a few reports of a user getting another user's session
> > > > > data.
> > > > > It's been rare,
> > > > > but is still quite serious for us. Wondered if anyone else has
> > > > > experienced this with any version of Jrun 2.3.3 157 or higher
> > > > > or Jrun 3
> > > > > or 3.1? Or even
> > > > > any other servlet engine?
> > > > >
> > > > > I read this past week either on this list or in the forums
> > > > > where someone
> > > > > reported wtih 3.0 sp2a having a problem with 2 users from two
> > > > > different
> > > > > IP's
> > > > > getting the same session id assigned. I'm trying to get an
> > > > > idea of how
> > > > > common this is? Or if anyone has any experiences that helped
> > > > > them log
> > > > > or
> > > > > understand this better.
> > > > >
> > > > > Thanks,
> > > > > Lynn
> > > > >
> > > > > Archives:
> > > > > http://www.mail-archive.com/[email protected]/
> > > > > Unsubscribe:
> > > > http://www.houseoffusion.com/index.cfm?sidebar=lists
> > > >
> > > >
> > > > =====
> > > > Nilanjana ChakravartyE-Business Division , SES Oracle,Satyam
Computer
> > > Services, TSR Towers, 5th floorRajbhavan Road,Hyderabad,India Tel:
> +91-
> > > 040-3304819 X7528 (Work) +91- 040-3532715 (Res) email to
> > > [EMAIL PROTECTED]
> > > >
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
