Hi, we are using JDBC Cache loader as a read only cache. We are pre-loading all the data at the server startup. But we observe that every time we make cache request for reading data in the cache, the configured jdbc cache loader performs a database query (Select sql statement). Initially we thought that it is trying to fetch data for the first time, however behaviour repeats for the subsequent requests. Can you please explain why the jdbc cache loader behaves in this manner and how to avoid repeated reads to the database. Further we are seeing a drastic drop in the number of requests that can be handled by the server(75%). Whereas the primary purpose of the cache is to increase the performance. Your help will be very timely. The cache configuration used is as follows, <?xml version="1.0" encoding="UTF-8"?> <!-- ===================================================================== --> <!-- --> <!-- Sample TreeCache Service Configuration --> <!-- --> <!-- ===================================================================== --> <!-- ==================================================================== --> <!-- Defines TreeCache configuration --> <!-- ==================================================================== --> jboss:service=Naming jboss:service=TransactionManager <!-- Configure the TransactionManager --> com.hp.tpf.cos.runtime.TPFCoSTxManagerLookup <!-- Isolation level : SERIALIZABLE REPEATABLE_READ (default) READ_COMMITTED READ_UNCOMMITTED NONE --> READ_COMMITTED <!-- Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC --> REPL_SYNC <!-- Just used for async repl: use a replication queue --> false <!-- Replication interval for replication queue (in ms) --> 0 <!-- Max number of elements which trigger replication --> 0 <!-- Name of cluster. Needs to be the same for all clusters, in order to find each other --> My-Cluster <!-- JGroups protocol stack properties. Can also be a URL, e.g. file:/home/bela/default.xml --> <!-- UDP: if you have a multihomed machine, set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr="192.168.0.2" --> <!-- UDP: On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense) set the loopback attribute to true --> <UDP mcast_addr="224.1.2.3" mcast_port="45566" ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000" ucast_recv_buf_size="80000" loopback="false" bind_addr="15.76.223.149"/> <PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false"/> <MERGE2 min_interval="10000" max_interval="20000"/> <!-- <FD shun="true" up_thread="true" down_thread="true" />--> <FD_SOCK/> <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false"/> <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" max_xmit_size="8192" up_thread="false" down_thread="false"/> <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false"/> <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false"/> <FRAG frag_size="8192" down_thread="false" up_thread="false"/> <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true"/> <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/> <!-- Whether or not to fetch state on joining a cluster --> true <!-- The max amount of time (in milliseconds) we wait until the initial state (ie. the contents of the cache) are retrieved from existing members in a clustered environment --> 5000 <!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> 10000 <!-- Max number of milliseconds to wait for a lock acquisition --> 15000 <!-- Name of the eviction policy class. Not supported now. --> <!-- org.jboss.cache.loader.bdbje.BdbjeCacheLoader c:\tmp\bdbje true / --> <!-- org.jboss.cache.loader.FileCacheLoader /tmp true / --> <!-- if passivation is true, only the first cache loader is used; the rest are ignored --> false <!-- comma delimited FQNs to preload --> / <!-- are the cache loaders shared in a cluster? --> true <!-- we can now have multiple cache loaders, which get chained --> <!-- the 'cacheloader' element may be repeated --> org.jboss.cache.loader.JDBCCacheLoader <!-- same as the old CacheLoaderConfig attribute --> cache.jdbc.table.name=TPFCoSProvCache cache.jdbc.table.create=false cache.jdbc.table.drop=false cache.jdbc.fqn.column=fqn cache.jdbc.fqn.type=varchar(255) cache.jdbc.node.column=node cache.jdbc.node.type=blob cache.jdbc.parent.column=parent cache.jdbc.driver=oracle.jdbc.OracleDriver cache.jdbc.url=jdbc:oracle:thin:@msdp1.india.hp.com:1521:TPFDB cache.jdbc.user=dharani cache.jdbc.password=dharani <!-- whether the cache loader writes are asynchronous --> false <!-- only one cache loader in the chain may set fetchPersistentState to true. An exception is thrown if more than one cache loader sets this to true. --> false <!-- determines whether this cache loader ignores writes - defaults to false. --> false <!-- if set to true, purges the contents of this cache loader when the cache starts up. Defaults to false. --> false <!-- Uncomment to get a graphical view of the TreeCache MBean above --> <!-- --> <!-- jboss.cache:service=TreeCache--> <!-- jboss.cache:service=TreeCache--> <!-- --> Thanks & Regards, Swami View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036736#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...