tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis <>
Subject Re: DeltaManager for Clustering
Date Fri, 29 Jul 2005 20:44:40 GMT
Rainer Jung wrote:

>Hi Dennis,
>assuming you have a valid cluster config you don't need to start/stop the
>DeltaManager yourself.
Good, that's what I thought.

>Session attributes are only replicated, if they are serializable and the
>changes to the attributes are applied via setAttribute. If your attribute
>e.g. is a HashMap and you change an entry via getAttribute and then access
>by a key, the cluster will not know about the change and not replicate the
>new data. On the other hand this way you can obscure changes you don't
>really need from the replication and save some replication load.
See, the thing is, we have a 3rd party library that saves information in
the session.  It doesn't call setAttribute every time it changes the
data.  DeltaManager appears to ignore the useDirtyFlag.  With
SimpleTcpReplicationManager, I can set useDirtyFlag to false and we get
the desired behavior.  With DeltaManager, the sessions get out of sync. 
So for the time being, I switched the managerClass back to
SimpleTcpReplicationManager and things work the way they are supposed to.

The issue is whether or not DeltaManager is supposed to use a
useDirtyFlag or not I guess.  The config option is still there in the
sample cluster config that comes with server.xml as well as in the
online-documentation.  It has no effect though.

>Is replication working in general in your setup?

Thanks for your reply.

>>Is there documentation on using the DeltaManager for clustering?
>>In the javadoc there is this statement:
>>Correct behavior of session storing and reloading depends upon external
>>calls to the start() and stop() methods of this class at the correct
>>The tomcat clustering howto doesn't mention this though.  Are the
>>start/stop calls referred to for the container, or does the user
>>application have to do something?
>>I have some objects in the session that are not being syncronized
>>accross the cluster and am trying to figure out if I'm doing something
>>wrong either in the config or in the code.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message