1:11 p.m.
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. 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-->
<!-- -->
We are seeing this issue in 1.2.x and 1.4.1SP3. Is it because a get call always goes to
the persistent store?
Thanks & Regards,
Swami
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036829#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...