RE: tomcat 5.0.28 cluster with useDirtyFlag="false" and NO session.setAttribute(...) within request.
Hello Filip,
got it. Decided to stick with DeltaManager and update the session programmatically.
Thanks a lot for you time.
Rolf
-Original Message-
From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 15, 2004 5:57 PM
To: Tomcat Users List
Subject: Re: tomcat 5.0.28 cluster with useDirtyFlag="false" and NO
session.setAttribute(...) within request.
hi rolf,
the use dirty flag only works with the SimpleTcpReplicationManager,
not the delta manager, so replace DeltaManager in server.xml with
SimpleTcpReplicationManager
note, that this will replicate the entire session on each request, you are probably
better off just fixing your code
Filip
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 15, 2004 3:24 AM
Subject: tomcat 5.0.28 cluster with useDirtyFlag="false" and NO
session.setAttribute(...) within request.
Hello all,
We have the following tomcat cluster setup:
- Reverse Proxy:
Apache reverse proxy which distributes every request to different tomcat instance.
Works fine.
- Tomcat Cluster:
Cluster with 2 instances, pooled synchronization using mcast, useDirtyFlag="false"
Replication as such works fine except to the following code:
A)
-- code snipped --
SessionContext sessionContext = getSessionContext(request); //
session.getAttribute("session.context");
sessionContext.setSelectedParticipant("11"); // previous value e.g. is "10"
-- code snipped --
With this code above, we read an already and successfully replicated object
(sessionContext) from the session. After fetching the
object, we modify one of its values. Please note, we do not call
session.setAttribute(...) in this scenario.
Having the useDirtyFlag="false", we expect the whole session beeing replicated
everytime before the request has ended (pooled
synchronization). However, on the next request (to the second tomcat instance)
getSelectedParticipant() still returns "10". The
following request to the first tomcat instance shows the changed value "11".
B)
If we change our code to the following, session replication works and will show value
"11" in both cases:
-- code snipped --
SessionContext sessionContext = getSessionContext(request); //
session.getAttribute("session.context");
sessionContext.setSelectedParticipant("11"); // previous value e.g. is "10"
request.getSession().setAttribute(
SessionContext.CONTEXT_KEY,
sessionContext);
-- code snipped --
Please note, that in scenario B) we have explicitly called session.setAttribute(...),
means we are replacing a session attribute.
With this, the session get replicated successfully.
Did we missunderstand the useDirtyFlag="false" for scenario A) in combination with
pooled synchronization? Any help is warmly
appreciated.
Best Regards,
Rolf Schenk
Rolf B. Schenk
Equate+ IT Architecture & Development
CEFS EU
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.0.28 cluster with useDirtyFlag="false" and NO session.setAttribute(...) within request.
hi rolf,
the use dirty flag only works with the SimpleTcpReplicationManager,
not the delta manager, so replace DeltaManager in server.xml with
SimpleTcpReplicationManager
note, that this will replicate the entire session on each request, you are probably
better off just fixing your code
Filip
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 15, 2004 3:24 AM
Subject: tomcat 5.0.28 cluster with useDirtyFlag="false" and NO
session.setAttribute(...) within request.
Hello all,
We have the following tomcat cluster setup:
- Reverse Proxy:
Apache reverse proxy which distributes every request to different tomcat instance.
Works fine.
- Tomcat Cluster:
Cluster with 2 instances, pooled synchronization using mcast, useDirtyFlag="false"
Replication as such works fine except to the following code:
A)
-- code snipped --
SessionContext sessionContext = getSessionContext(request); //
session.getAttribute("session.context");
sessionContext.setSelectedParticipant("11"); // previous value e.g. is "10"
-- code snipped --
With this code above, we read an already and successfully replicated object
(sessionContext) from the session. After fetching the
object, we modify one of its values. Please note, we do not call
session.setAttribute(...) in this scenario.
Having the useDirtyFlag="false", we expect the whole session beeing replicated
everytime before the request has ended (pooled
synchronization). However, on the next request (to the second tomcat instance)
getSelectedParticipant() still returns "10". The
following request to the first tomcat instance shows the changed value "11".
B)
If we change our code to the following, session replication works and will show value
"11" in both cases:
-- code snipped --
SessionContext sessionContext = getSessionContext(request); //
session.getAttribute("session.context");
sessionContext.setSelectedParticipant("11"); // previous value e.g. is "10"
request.getSession().setAttribute(
SessionContext.CONTEXT_KEY,
sessionContext);
-- code snipped --
Please note, that in scenario B) we have explicitly called session.setAttribute(...),
means we are replacing a session attribute.
With this, the session get replicated successfully.
Did we missunderstand the useDirtyFlag="false" for scenario A) in combination with
pooled synchronization? Any help is warmly
appreciated.
Best Regards,
Rolf Schenk
Rolf B. Schenk
Equate+ IT Architecture & Development
CEFS EU
UBS AG
Buckhauserstrasse 22
8048 Zürich
+41-1-2348594
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
tomcat 5.0.28 cluster with useDirtyFlag="false" and NO session.setAttribute(...) within request.
Hello all,
We have the following tomcat cluster setup:
- Reverse Proxy:
Apache reverse proxy which distributes every request to different tomcat
instance. Works fine.
- Tomcat Cluster:
Cluster with 2 instances, pooled synchronization using mcast,
useDirtyFlag="false"
Replication as such works fine except to the following code:
A)
-- code snipped --
SessionContext sessionContext = getSessionContext(request); //
session.getAttribute("session.context");
sessionContext.setSelectedParticipant("11"); // previous value e.g. is "10"
-- code snipped --
With this code above, we read an already and successfully replicated object
(sessionContext) from the session. After fetching the object, we modify one of its
values. Please note, we do not call session.setAttribute(...) in this scenario.
Having the useDirtyFlag="false", we expect the whole session beeing replicated
everytime before the request has ended (pooled synchronization). However, on the next
request (to the second tomcat instance) getSelectedParticipant() still returns "10".
The following request to the first tomcat instance shows the changed value "11".
B)
If we change our code to the following, session replication works and will show value
"11" in both cases:
-- code snipped --
SessionContext sessionContext = getSessionContext(request); //
session.getAttribute("session.context");
sessionContext.setSelectedParticipant("11"); // previous value e.g. is "10"
request.getSession().setAttribute(
SessionContext.CONTEXT_KEY,
sessionContext);
-- code snipped --
Please note, that in scenario B) we have explicitly called session.setAttribute(...),
means we are replacing a session attribute. With this, the session get replicated
successfully.
Did we missunderstand the useDirtyFlag="false" for scenario A) in combination with
pooled synchronization? Any help is warmly appreciated.
Best Regards,
Rolf Schenk
Rolf B. Schenk
Equate+ IT Architecture & Development
CEFS EU
UBS AG
Buckhauserstrasse 22
8048 Zürich
+41-1-2348594
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
