Scoping the way I intend to implement it will require more threads, conceptually 1 thread per scope. Of course, that's not the way I'll implement it, but I;'ll use a thread pool instead. However, if we have 65'000 scopes, then ideally we would have a thread pool which supports up to 65'000 threads. Of course, this is only if we get 65'000 messages, each for a different scope *at the same time*.
I was thinking of reusing the thread pools from the transport, but if a pool has a DISCARD rejection policy, I might be in trouble as a message passed up to SCOPE cannot be discarded as NAKACK or UNICAST consider it delivered, so we won't receive it again !
As per the discussion on cluster-dev, web and SFSB sessions could be grouped together so that they are co-located on the same node (related to ISPN-359). This only really makes sense if they use the same CacheManager/Channel though.
Re 3) For the same reason, wouldn't it make sense for the same cache manager to be used for Web+SFSB+Hibernate? A web request is likely to modify an SFSB and then create/update an entity, isn't it?