After a little more digging, I noticed that the command ClusteredCacheLoader was not chained because it issued the command GetCacheDataMap to get data from remote server, while GetCacheDataMap gets data only from memory by calling NodeSPI#getDataDirect(). Is this correct observation? If if it is, could anyone please let me know why ClusteredCacheLoader is designed like that? If I replace NodeSPI#getDataDirect() with NodeSPI#getData() so CacheLoaderInterceptor will be used, would I run into any issue? By the way, ClusteredCacheLoader implements its exits(Fqn fqn) method by issuing a remote ExistsCommand. May I know why it should know whether a remote server has data or not? I thought if GetDataMapCommand would suffice because ClusteredCacheLoader would know a remoter server does not have the request data if GetDatamapCommand returns null. <div>
<br></div><div>Thanks, </div><div><br></div><div>Yong<br><div><br><div class="gmail_quote">On Fri, Apr 24, 2009 at 7:21 PM, Yong Yuan <span dir="ltr">&lt;<a href="mailto:yycslab@gmail.com">yycslab@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi, <div><br></div><div>I have two servers, server A and server B, each running a JBoss cache instance. Server A uses server B as a far cache. The cache instance on server B also uses a database as a persistent cache store. Server A has ClusteredCacheLoader as its only loader, and server B has ClusteredCacheLoader as its first loader and JDBCCacheLoader as its second loader. My question is, Can server A get a cached state that is *only* in the persistent cache store? Below is the flow I imagined:</div>

<div><br></div><div>              get cached state                                               calls ClusteredCacheLoader                                           calls JDBCCacheLoader</div><div>Server A ----------------------------&gt; cache instance on server A ----------------------------------------&gt; cache instance on server B ------------------------------------&gt; persistent cache store</div>

<div><br></div><div>I&#39;m asking this question because I noticed when a cache state was only in persistent cache store, server A would not be able to get that state. I turned on the traces on both servers. The log on server A showed ClusteredCacheLoader did make a remote call with ClusteredGetCommand and correct fqn being sent to server B. The log on server B showed that server B did receive the remote call from server A. Server B then executed ClusteredGetCommand, which in turn executed ExistsCommand first and then GetDataMapCommand. Since the requested cache was not in the memory, both commands returned false or null. Unfortunately, the chain execution ended here. No JDBC call was issued after GetDataMapCommand returned [false, null] to server A. As a result, server A always got null instead of the state in the persistent store. </div>

<div><br></div><div>Can I update my configuration files to enable command chaining or something familiar? That is, when ClusteredGetCommand in server B doesn&#39;t get anything from memory, JDBCCacheLoader will be executed to get the data from database. Or some customization is needed here? By the way, CommandAwareRpcDispatcher said ClusteredGetCommand &quot;.. is a non-visitable command - so performing directly and not via the invoker.&quot;, so somehow interceptor chaining was bypassed. </div>

<div><br></div><div>Any suggestion is greatly appreciated. </div><div><br></div><div><br></div><div>Thanks, </div><div><br></div><font color="#888888"><div>Yong</div>
</font></blockquote></div><br></div></div>