Thank you to Dan and Chris for your valuable comments.

On 1/19/15 9:21 AM, Daniel Mikusa wrote:
> Question 1: Is the documentation still correct after all these years of 
> BackupManager being used? Is it still considered of lower reliability?
> 
> It's just saying that less people use it. Because DeltaManager is the default 
> and works fine in a lot of cases, the majority of users are just going to 
> stick with it. Naturally then less people use BackupManager. It's not 
> implying that BackupManager has problems. I've see BackupManager used a bunch 
> of times and it worked great every time. 


Great. Then just as a summary, let me outline the options:

Choice 1: to stick or not to stick
If you use sticky sessions, then any session persistence layer is just there as 
a backup in case of failure of that node. So, for example, memcache would be 
used almost entirely to write entries and is never read from. If you don't use 
sticky sessions, then the session persistence layer becomes a new point of 
failure and needs its own redundancy and load balancing.


Choices 2: which backend

* JDBC
* memcache
* backup manager (can only be used in sticky mode)
* delta manager


For my needs I think the backupManager is the way to go. No extra moving parts, 
very simple to implement and not too much extra network traffic.


On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz wrote:
> My question would be whether you are engineering to solve a problem that does 
> not yet exist. We went through this conversation years ago at $work, and 
> decided that users having to re-authenticate in the event of a failure was an 
> okay compromise given all the work it would require to keep a 
> high-availability cluster up and running. Our user's needs simply aren't that 
> critical.


This is actually designed to make our life easier with sysadmin more than 
anything. We can then take an instance offline to adjust memory usage, attach a 
profiler or anything else, without worrying about doing it out of hours or 
slowly waiting for all sessions to expire.

If you have commit rights to the tomcat documentation, can I suggest that you 
add your notes about HttpSession.setAttribute(). That hint is absolutely 
invaluable!

Thanks
Ari




-- 
-------------------------->
Aristedes Maniatis
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to