Mika, Costin: While pondering things yesterday, the thought occured to me as well, perhaps this whole notion of distributed management had a wider application (beyond simply HttpSessions).
Having said that. I disagree, that Tomcat should expose an 'object replication service' api to web-application writers. Such a thing is clearly NOT a standard. Tomcat developers, on the other hand, may, over-time find other uses for such a mechanism. If we were to create such a generic object replication service, it should be packaged separately from Tomcat This, however, is secondary to my primary goal. So, I will be providing abstractions where it seems to make the most sense. But I definately want to keep things as simple as possible, and not 'over-design' this thing. I'd like to create a working solution that solves the real business problems (discussed ad nauseum on this list). Tom ----- Original Message ----- From: "Mika Goeckel" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 3:24 AM Subject: Re: Tomcat: Distributed Session Management revisited | 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]> | | | -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
