Costin, that point of view is really interesting. What about separating the distribution part from the integration part of a integrated solution. That would user's give the option to use the "transparent session replication" or to use "explicit object replication services". The former would ease their live with the drawback of missing transaction support, the latter would give the app-developer all control over it.
M. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, November 14, 2001 6:27 PM Subject: Re: Tomcat: Distributed Session Management revisited > To clarify: creating a Distributed Session Manager is a good idea, and > something that would be great for users. > > My problem is with designing it at container-level, as an implementation > of the servlet session API. > > Having all objects in a session distributed and no control or feedback is > not good. > > You could have a DSMServlet that would have some init parameters in > web.xml. There you can specify what classes/interfaces you want > 'distributed', or even what attributes ( by name ). > > Then you can use the existing listeners and notifications to detect when > those objects are saved in the session and do the distribution. > > You could also define a simple API allowing the user to control this - for > example and update() method to be called after the user changes an object. > > What's different here is that the behavior of servlet sessions doesn't > change - most objects can still be stored without an overhead. The user > gets to choose what objects to persist/distribute and he has control over > the process. And this will work in _any_ container, so the user can assume > the objects he marks as persistent/distributable will be this way on any > container ( you can't force people to switch to a different container to > use your webapp ) > > You can also define specialized interfaces to be implemented by the > objects that will be persisted/distributed. > > All of this can be done with only standard 2.3 support. A container may > provide aditional hooks ( valves, interceptors, etc) of course. > > Costin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
