On Tue, 13 Nov 2001, Tom Drake wrote: > | One question - wouldn't be better if the 'distributed session management' > | would be first designed and discussed _outside_ of the ServletSession > | context ? > > I agree. > > | Designing the SessionManager as a standalone component would make a lot of > | sense - you can then integrate it with the servlet sessions, or the user > | could use its richer API. > > True, but I'm not sure that exposing a Session Manager api to the > application > programmer is a good idea. It's not part of the Servlet API, for one thing. > For another, many people have a difficult enough time just understanding > the existing api. (witness recent discussions on the tomcat-user list re: > "non-serializable objects in sessions").
Well, I have a difficult enugh time understanding how someone could stretch the existing session API ( getAttribute/setAttribute, no exception, arbitrary Objects ) to be used for anything but simple storage of data with no guarantee. Fiting a (mini) fault-tolerant, object oritened database in those 2 methods is quite challenging, and I doubt too many people will be able to use this. In addition, the servlet API is not intended as an API for data storage - there are other APIs that are designed for that. The session support is nice and convenient - but stretching it beyond what it can express can create many problems and unexpected behavior. > | IMHO no sane user should store something in a servlet session and assume > | the operation will be sucessful - and the session manager can only give a > | dangerous ilusion that this is possible. Nothing can be guaranteed to > | allways succeed ( no database or network application can do that ) - and > | with an API that doesn't provide any feedback there's little you can do. > > In any servlet container, one must be able to count on this functionality. > In a distributed environment, it is encumbant on the application > programmer to ensure that any objects placed in the servlet container > are serializable (It says this in the servlet spec - I don't remember the > section number - possibly 7.7.3) What I'm saying is that there is no way to guarantee that a certain operation will succeed, writing to a file or socket can throw an exception - while setAttribute() can't, so there is no way to tell the user that his operation failed. And the fact that an object is Serializable doesn't mean the user wants it copied over network every time he changes an attribute - it may be just a big photo he can retrieve from disk if it's not in memory. You can't guess which objects are just cached in memory and which are important - so you have to save everything. Again - the problem is the attempt to fit an API that was not designed for safe data storage into the wrong problem. This is deep into object-oriented database problem space - Serializable was designed to allow the object to be saved/restored, but it is also not the right API for an OODB - it can't detect changes in a field ( and call persist ), can't diferentiate what/when the user wants persisted ( there is no explicit method ), etc. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
