3 Replies Latest reply on Apr 19, 2010 7:01 AM by Galder Zamarreño

    Exposing Infinispan CacheManager's in the AS

    Brian Stansberry Master

      Discussion thread related to https://jira.jboss.org/jira/browse/JBAS-7838


      I was talking to Bela today about adding scopes to JGroups messages (see https://jira.jboss.org/jira/browse/JGRP-822) and the solution to that is still a bit up in the air. He's got clear ideas and may have something done pretty shortly, but IMO it's risky for the AS to count on having a scoping solution in JGroups and consumed by Infinispan in time for AS 6.0 M4.


      Without a good scoping solution, I think it's wise to have different services (i.e. web session management, SFSB management, Hibernate 2LC, HAPartition) use a separate JGroups channel. Otherwise messages from one service will block in the receiver's NAKACK/UNICAST behind other messages from the same sender for different services.


      This means we would use a different CacheManager for the different services. JBAS-7838 says to just use one by default, but I'm pretty convinced we should have more than one. We need to support that in the long run anyway.


      Options, comments are appreciated:


      1) Everything shares a single CacheManager/Channel.


      2) 4 separate channels:  Web, SFSB, Hibernate, HAPartition. A la AS 5.


      3) 3 separate channels: Web+SFSB, Hibernate, HAPartition.  Here web sessions and SFSBs use the same channel, which can be useful in the future when Infinispan supports sending a single 2PC message pair at tx commit for a tx that crosses several caches. So, a web request modifies a session and modifies an SFSB, we could get a single 2PC.


      Hmm, if the web session and SFSB mapped to different nodes with DIST, there would be 2 messages anyway, so the utility of #3 is less.


      So, I'm leaning toward #2 but am quite open to persuasion.