> > 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.
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.
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.
jr
> > jr
> >
> > >
> > > Craig
> > >
> > >
> >
>
> Craig
>
>
