--- Carlos Gaston Alvarez [EMAIL PROTECTED]
We have an instance of the database to store the
sessions.
What does the database mean? If we're persisting
the sessions to a real RDBMS, then that's a serious
performance hit above and beyond just having to
serialize the session whenever it's
]
To: [EMAIL PROTECTED]
Sent: Friday, August 24, 2001 8:51 PM
Subject: RE: Addition of 'dirty' field to Session interface
This is just an idea from the top of my head, would
it be possible
having a second vector that contains a footprint(not
a full clone) of
the
object for a session
For permanent business objects, that is probably true ... but the use
cases we'd like to be able to deal with include:
* Load-balanced distributed container that can move sessions around
as various servers get overloaded.
* Fail-safe distributed container that automatically recovers
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
[...]
* Load-balanced distributed container that can move sessions around
as various servers get overloaded.
* Fail-safe distributed container that automatically recovers from
server failures and
--- Bip Thelin [EMAIL PROTECTED] wrote:
This is just an idea from the top of my head, would
it be possible
having a second vector that contains a footprint(not
a full clone) of
the
object for a session and have a reaper thread
checking the footprints
against
the real objects and
This is just an idea from the top of my head, would
it be possible
having a second vector that contains a footprint(not
a full clone) of
the
object for a session and have a reaper thread
checking the footprints
against
the real objects and determine if they changed or
not
Craig R. McClanahan typed the following on 12:40 PM 8/9/2001 -0700
Now that I think about it though, any time a session is used in a request,
its
lastAccessedTime will be updated, so the session must be considered dirty.
So worrying about tracking attributes isn't necessary: the session only
On Fri, 10 Aug 2001, Kief Morris wrote:
Craig R. McClanahan typed the following on 12:40 PM 8/9/2001 -0700
Now that I think about it though, any time a session is used in a request,
its
lastAccessedTime will be updated, so the session must be considered dirty.
So worrying about
Craig R. McClanahan typed the following on 12:57 PM 8/8/2001 -0700
Another possibility would be to flag the session is dirty when getAttribute()
is called - it would result in unnecessary saves since it assumes the
attribute
was modified even when it wasn't, but it would be safer.
Someone
On Thu, 9 Aug 2001, Kief Morris wrote:
Craig R. McClanahan typed the following on 12:57 PM 8/8/2001 -0700
Another possibility would be to flag the session is dirty when getAttribute()
is called - it would result in unnecessary saves since it assumes the
attribute
was modified even
Jim Seach typed the following on 04:29 PM 8/7/2001 -0700
Selected setXXX methods in StandardSession will set the dirty bit to
true indicating that Session data has changed and it needs to be
saved
in the next save cycle by PersistentManager.
But what happens if in one servlet you put an
On Wed, 8 Aug 2001, Kief Morris wrote:
Jim Seach typed the following on 04:29 PM 8/7/2001 -0700
Selected setXXX methods in StandardSession will set the dirty bit to
true indicating that Session data has changed and it needs to be
saved
in the next save cycle by PersistentManager.
: Re: Addition of 'dirty' field to Session interface
Jim Seach typed the following on 04:29 PM 8/7/2001 -0700
Selected setXXX methods in StandardSession will set the dirty bit to
true indicating that Session data has changed and it needs to be
saved
in the next save cycle by PersistentManager
--- Vishy Kasar [EMAIL PROTECTED] wrote:
Hi,
In order to support persistent failover, we have written our own
Store
class that writes session data to DB of our choice. We decided to use
maxIdleBackups as that will save the data periodically to disk
without
getting rid of it in memory.
14 matches
Mail list logo
