-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yves,
On 6/17/2009 6:04 AM, Yves Glodt wrote: > In my setup are 4 apaches with mod_proxy which connect to 4 tomcats. > In front of the apaches is a hardware balancer which does > round-robin, but with a kind of sticky TCP-sessions, so mostly the > clients on the web stay on the same server. Mostly... Why not use mod_jk's session stickiness? The httpd server can be chosen randomly by the hw lb, but the "right" Tomcat always gets the request. Then, you can forget about session replication and get better performance. On the other hand, if your users cannot be expected to tolerate interruptions (due to a failing server) then you'll /have/ to go with some kind of replication. > To be completely safe and sleep well, I would like to replicate the > sessions now, and in the mentioned document I read that it is > possible using the PersistenceManager with JDBCStore. Just note that this is probably the slowest of the 3 options presented in the Replication HOWTO, since each session attribute will have to be retrieved from the database every time. Option #3 (in-memory replication) will probably be the fastest option for a cluster such as yours, especially if all the members of the cluster are on the same (real) network. > My question now: Is it enough to set up PersistenceManager with > JDBCStore on my 4 tomcats to use the same database/table as session > store ? It should be. > Or do I need to mess with ReplicationValve and jvmRoute set up as > well ? No, but I think using "real" replication will give you better performance. > I will put my server.xml at the end of the file, which is set up > with JDBCStore using a Firebird Database with JayBird. How are you sharing your database across your 4 Tomcat instances? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5RwoACgkQ9CaO5/Lv0PDK/wCffEK2IfLU3urah7UO4c8+NV2w VOMAn2ly1yE2CO3+PdglPRj2k9plFn5F =qeVK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org