This creates a problem for mutable objects, because if you read a mutable session object, change its state, but don't invoke setAttribute(), the changes will be isolated to just a single server in the cluster.
Tapestry attempts to solve this: any session persisted object that is read during a request will be re-stored back into the HttpSession at the end of the request. This ensures that changed internal state of those mutable objects is properly replicated around the cluster.
This can be a problem in a cluster as all those calls to setAttribute() may impact performance, as often the internal state of the mutable object don't have changed.
Tapestry has solutions to this.
Tapestry knows that Java's String, Number and Boolean classes are immutable. Immutable objects do not require a re-store into the session.
You can mark your own session objects as immutable using the ImmutableSessionPersistedObject annotation.
The OptimizedSessionPersistedObject intece allows an object to control this behavior. An object with this intece can track when its mutable state changes. Typically, you should extend from the BaseOptimizedSessionPersistedObject base class.
The SessionPersistedObjectAnalyzer service is ultimately responsible for determining whether a session persisted object is dirty or not (dirty meaning in need of a restore into the session). This is an extensible service where new strategies, for new classes, can be introduced.
When integrating Tapestry with legacy applications it is often required to read or to write some data from or into the HttpSession.
Since 5.2 this can be accomplished just by annotating a page or component property with @SessionAttribute. This annotation is used to map a property of a page or component to value stored in session. The name of the annotated property is used as the name of the session attribute to look for. You can also provide a name by binding the value parameter of the annotation.
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-30936-4.html
假的
我们坚持捍卫