--- 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'
AIL PROTECTED]>
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 vect
> > 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
--- 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
> -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
> 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 re
On Fri, 24 Aug 2001, Reilly, John wrote:
> Date: Fri, 24 Aug 2001 18:59:03 +0100
> From: "Reilly, John" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: Addition of 'dir
> > Also, I don't think its a good
> > thing for the developer to have to indicate that a session is dirty.
> >
>
> I agree with the feeling, but what alternatives do we have?
>
> Consider that I might have an Employee bean with a "name"
> property, and I
> add it to my session:
>
> Employ
On Fri, 24 Aug 2001, Reilly, John wrote:
> Also, I don't think its a good
> thing for the developer to have to indicate that a session is dirty.
>
I agree with the feeling, but what alternatives do we have?
Consider that I might have an Employee bean with a "name" property, and I
add it to my
Sorry for the late reply, but anyway
> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 10 August 2001 16:31
> To: [EMAIL PROTECTED]
> Subject: Re: Addition of 'dirty' field to Session interface
>
>
>
>
>
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
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 sessio
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 modifi
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.
>
>So
D]
Subject: 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
>&
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 PersistentM
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 pu
--- 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
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.
PersistentManagerBase.processMaxIdleBackups() writes
19 matches
Mail list logo
