You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2007/11/14 23:57:32 UTC

DO NOT REPLY [Bug 43866] New: - add support for session attribute propagation without calls to DeltaSession.setAttribute

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43866>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43866

           Summary: add support for session attribute propagation without
                    calls to DeltaSession.setAttribute
           Product: Tomcat 5
           Version: 5.5.23
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Catalina:Cluster
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: clucas@e-miles.com


This enhancement request is based on our misunderstanding of Tomcat clustering.
We were under the impression that we could use the "useDirtyFlag" attribute in
conjunction with DeltaManager to cause session replication to occur after each
request (vs only on certain requests that manipulate the session via
Session.setAttribute, etc.)  Apparently useDirtyFlag is not applicable to
DeltaManager.

In our scenario, this is problematic because we have a mutable object that is
stored in the session and manipulated after a call to Session.getAttribute but
not followed by a new call to Session.setAttribute.  Because there is no
setAttribute call, the session is not propagated.

Our "fix" was to add a call to the internal version of DeltaSession.setAttribute
(not notifying listeners) from within DeltaSession.getAttribute.  If desired and
with some direction, I could submit a patch that would make this behavior
configurable.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org