Hi,
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:
get cached state
calls ClusteredCacheLoader calls
JDBCCacheLoader
Server A ----------------------------> cache instance on server A
----------------------------------------> cache instance on server B
------------------------------------> persistent cache store
I'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.
Can I update my configuration files to enable command chaining or something
familiar? That is, when ClusteredGetCommand in server B doesn'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 ".. is a non-visitable command - so performing
directly and not via the invoker.", so somehow interceptor chaining was
bypassed.
Any suggestion is greatly appreciated.
Thanks,
Yong