See my comments below. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 2:08 PM Subject: Re: Tomcat: Distributed Session Management revisited
| 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. That's how I read the 2.3 serlvet spec. | | 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. | But it is an api for storing things temporarily - for the lifetime of a session. JSP's have built-in support for session scoped application beans - which can be arbitrarily complex objects. I think you have to be able to depend on the integrity of HttpSession attributes. SRV 7.7.2 opens up with : Within an application marked as distributable, all requests that are part of a session must handled by one virtual machine at a time. The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately. The following restrictions are imposed to meet these conditions: . The container must accept objects that implement the Serializable interface . The container may choose to support storage of other designated objects in the HttpSession, such as references to Enterprise JavaBean components and transactions. . Migration of sessions will be handled by container-specific facilities. | | > | 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. True, but, in a distributed environment, if network operations fail, there's typically not too much that we can be expected to do, aside from returning a message to the client. | | 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. However, if the user has stored a Serializeable object in her session in a distributed environment, the documented semantics (in the servlet spec section 7.7.2) indicate that if a session attribute is seriablizable you can expect the container may move the session to other nodes in the network. You only have to save the Serialized objects - interestingly, you don't actually have to use writeObject(), but you have to retain the closure that it provides. | | 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. Agreed. However, see my response to Craigs statement where I talk about optimistic and pessimistic assumptions. Tom -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
