Ted - You can think of this as a problem with using singleton in a multi-threaded program. The solution that provides better code readability at affordable cost should win.
Specifically the problem I am trying to solve is this: We have a multi-threaded webapp based on a framework (means I am not yet able to find out how the framework spawns threads, cleaning up the threads). Each thread has local states that must be cleaned up on zookeeper fatal error; and the desired zookeeper error recovery is to reopen the session. The choices on the table are: 1. 1 zk session for the whole webapp 2. 1 zk session for each thread Option 1 proves to be tricky to implement - since more than 1 threads can catch zk fatal error, I would have to implement proper synchronization mechanism to prevent same session being closed/reopened rapidly back to back; besides, I need to implement a way to request the threads that did not catch zk fatal error to clean up their local states. Option 2 I haven't prototyped out completely. It is likely the webapp may become laden with zk threads. I suspect we'll run into zk threads race condition. I'd like to hear from people who actually struggled with similar design decision. Lei On Tue, Apr 27, 2010 at 7:12 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > Lei, > > A contrary question for you is why you don't just share zk sessions within > a > single process. > >
