[jboss-user] [JBossCache] - JDBCCache Loader

[swami_venkat]

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#4036829

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036829