tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reilly, John" <John.Rei...@xelector.com>
Subject RE: Addition of 'dirty' field to Session interface
Date Fri, 24 Aug 2001 17:59:03 GMT


> > 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
> 
> 

Mime
View raw message