Thank you for this summary. I was just trying to learn more about it. A few questions: 1. Do you plan to support external remote dedicated data tier machines such that no state is stored in the app server itself, but consumes data remotely with hotrod or something like this? 2. Would you say that load balancer session affinity is no longer required with DIST? Since hotrod and other protocols already do load balancing for the data tier, would it be possible to remove the HTTP-aware affinity and let the data tier do the intelligent part of the load balancing while the HTTP requests are just sprayed against the available nodes? 3. Do you acquire any cluster locks on the data in the cache during the request processing thread? (like cluster-wide thread synchronization) 4. Do you attempt to collocate the session attribues in the physical cache machine when using ATTRIBUTE-based replication and how? Otherwise isn't there too much effort fetching them separately if needed as bulk? (afaik https://issues.jboss.org/browse/ISPN-359 is the only plan to do it right now) 5. Is there something new from management perspective? For example would it be possible to read/persistent the configuration though some API or JMX or some other method? May be allow runtime changes without restart to test and adapt different configs depending on traffic and topology changes? On Tue, Dec 14, 2010 at 8:40 PM, Paul Ferraro <paul.ferraro(a)redhat.com&gt;wrote:

Good stuff Paul!! A few comments: - I wonder whether adding an example in "Under the hood" section might help better explain the main differences between previous model and the current one. For example: Before, all web apps' sessions where stored in the same JBC Cache instance under different subtrees. Now, within the web session cache container, there''s an Infinispan Cache for each individual web app. I think this is somehow mentioned later, but it'd good to provide an example when comparing old JBC and Infinispan. - In the infinispan-configs.xml, the section of "Individual cache container configurations can also be injected into an existing registry.". When would someone do this or would want to use this method? - In the "JPA/Hibernate 2nd Level Cache" section, you might wanna link to http://community.jboss.org/docs/DOC-14105 in case users want to configure more properties such as eviction/expiration ones? - In "Using Infinispan Directly", I don't understand what's the difference between the two XMLs shown there. They both create the same bean?? At least the name and type is the same... p.s. I think the cache injection stuff is really cool :) On Dec 14, 2010, at 8:22 PM, Brian Stansberry wrote: -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache

On Dec 15, 2010, at 7:46 PM, Paul Ferraro wrote: Sure, but this is just to give them an example of how different things are split. This might help users understand how they should be separating data for their apps in an Infinispan world as opposed to JBoss Cache. Yeah, explaining use cases will help people understand when to use each option. Right, to make sure I understand correctly, the first would be used by a user that wants to deploy his own cache container, with his own configuration explictly mentioned in the config. The second on the contrary relies on the config being available in the registry and the user configuration pointing to it? -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache

On 12/22/10 8:45 AM, Paul Ferraro wrote: Did the session ownership stuff end up not happening? Although not a cluster-wide lock on the data in the cache, session ownership represents a cluster-wide lock on the logical session, done at the web/sfsb container level. -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

Indeed we are interested in efficient ways to implement a lock like this. I think we have enough working information for now. Thanks a lot. On Wed, Dec 22, 2010 at 6:24 PM, Paul Ferraro <paul.ferraro(a)redhat.com&gt;wrote: