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 'dirty' field to Session interface
>
>
>
> > > 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:
> >
> > Employee bean = ...
> > session.setAttribute("employee", bean);
> >
> > and, later on, I call:
> >
> > bean.setName("New Name");
> >
> > through a reference to "bean" that I had kept from some previous
> > processing. How is the container supposed to know that this
> > attribute is
> > now dirty, unless the developer tells it so?
> >
>
> The problem is that if bean.setName("New Name") as above is part of the
> implementation of a generic set of classes for a particular piece of
> business logic, those classes should not need to know that its being used by
> a servlet and that it must notify the servlet container of a setDirty event.
>
Or the bean must do so itself, which is equally bad.
> Also, there may be cases where an object is updated and this object is not
> related to a single session, but a group of sessions. The example that
> comes to mind is that there exists an object stock of class Stock. The
> price of field is updated periodically by a thread. There may be a number
> of session attributes which reference, directly or indirectly the "stock"
> variable. Should my StockPriceUpdate package have to know about all the
> sessions that are using a particular instance of Stock and send a setDirty
> event to each session?
>
> I realise there is no easy answer to this, but as I said earlier, I don't
> think its right that the business logic should need to know about the
> servlet container. I don't have anything better to offer at the moment but
> I'll definitely think about this a bit more.
>
I'm open to suggestions on *any* answer to this, easy or not :-).
> Also, I suppose it could be argued that an object that is shared as I
> described should be implemented as an EJB (or similar) which is providing
> its own persistence.
>
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 from
server failures and reconnects you to a different one with your
session intact.
without the application developer having to worry about this for his/her
session beans. The first case isn't so hard -- the only time you have to
persist is when you are going to migrate, so you would just do it
unconditinally. The second case is harder, unless you can afford the
performance hit of persisting after *every* request.
I don't think there's a single policy that will cover all reasonable use
cases, so configurable selection of different policies is likely to be
useful.
> jr
>
Craig
