Important Session Semantics
=> Threading Issues
Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility for synchronizing access to session resources as appropriate.
=> Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine1 (“JVM”) 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.
Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility for synchronizing access to session resources as appropriate.
=> Distributed Environments
Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine1 (“JVM”) 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 JavaBeans components and transactions.
=> Migration of sessions will be handled by container-specific facilities.
The distributed servlet container must throw an IllegalArgumentException for objects where the container cannot support the mechanism necessary for migration of the session storing them.
The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable. Distributed servlet containers that are part of a J2EE implementation must support the mechanism necessary for migrating other J2EE objects.
These restrictions mean that the Developer is ensured that there are no additional concurrency issues beyond those encountered in a non-distributed container.
The Container Provider can ensure scalability and quality of service features like load-balancing and failover by having the ability to move a session object, and its contents, from any active node of the distributed system to a different node of the system.
If distributed containers persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.
Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session.
Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine, the developer cannot depend on static variables for storing an application state. They should store such states using an enterprise bean or a database.
=> 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 JavaBeans components and transactions.
=> Migration of sessions will be handled by container-specific facilities.
The distributed servlet container must throw an IllegalArgumentException for objects where the container cannot support the mechanism necessary for migration of the session storing them.
The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable. Distributed servlet containers that are part of a J2EE implementation must support the mechanism necessary for migrating other J2EE objects.
These restrictions mean that the Developer is ensured that there are no additional concurrency issues beyond those encountered in a non-distributed container.
The Container Provider can ensure scalability and quality of service features like load-balancing and failover by having the ability to move a session object, and its contents, from any active node of the distributed system to a different node of the system.
If distributed containers persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.
Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session.
Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine, the developer cannot depend on static variables for storing an application state. They should store such states using an enterprise bean or a database.
=> Client Semantics
Due to the fact that cookies or SSL certificates are typically controlled by the Web browser process and are not associated with any particular window of the browser, requests from all windows of a client application to a servlet container might be part of the same session. For maximum portability, the Developer should always assume that all windows of a client are participating in the same session.
No comments:
Post a Comment