8 Replies Latest reply on Apr 14, 2008 8:09 PM by Manik Surtani

    Jdbc Cahce Loader Issue

    Shanthi Shanmugam Newbie



      Hi,

      I am using JBoss cache(1.4.1SP8) in webapplication which is deployed in weblogic clustered environment. I have two management ports.I am using JDBC Cache Loader and cache is clustered across the weblogic portals.

      I started the portal1 server succeessfully and cache also started. All the records are in the DB also.When I start the Portal2 server, I stop the server by killing the process before completion of startup.

      Now the DB contains very less records. I think StoreEntireState method is called by Cacheloader and it replaces the records in the db with the data which was loaded in the cache during startup of portal2 server. is it true? plese help...

      My configuration details are below




      <!-- 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="47700"
      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="192.168.100.8"/>
      <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" discard_delivered_msgs="true"/>
      <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"/>



      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
      -->
      50000



      <!-- 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(500)
      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:@192.168.100.9:1521:TPFDB
      cache.jdbc.user=tpf
      cache.jdbc.password=tpf
      cache.jdbc.datasource=tpfDBDS

      <!-- 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. -->
      true
      <!-- 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




        • 1. Re: Jdbc Cahce Loader Issue
          Manik Surtani Master

          please post your config file again, using the CODE button.

          • 2. Re: Jdbc Cahce Loader Issue
            Manik Surtani Master

             

            "shanthi_jbosscache" wrote:

            I started the portal1 server succeessfully and cache also started. All the records are in the DB also.When I start the Portal2 server, I stop the server by killing the process before completion of startup.


            Which server do you stop? Portal1, Portal2 or the database server?

            • 3. Re: Jdbc Cahce Loader Issue
              Manik Surtani Master

              I think I see your problem anyway - try setting fetchPersistentState to false. You don't need to do this if your cache loader is shared.

              • 4. Re: Jdbc Cahce Loader Issue
                Shanthi Shanmugam Newbie

                Hi ,

                Cache loader is shared and fetch persistent state is true.Still I am getting the same problem when I stop the portal2 by killing the process .Please help me to solve the problem.


                <?xml version="1.0" encoding="UTF-8"?>
                
                <!-- ===================================================================== -->
                <!-- -->
                <!-- Sample TreeCache Service Configuration -->
                <!-- -->
                <!-- ===================================================================== -->
                
                <server>
                
                 <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
                
                
                 <!-- ==================================================================== -->
                 <!-- Defines TreeCache configuration -->
                 <!-- ==================================================================== -->
                
                 <mbean code="org.jboss.cache.TreeCache"
                 name="jboss.cache:service=TreeCache">
                
                 <depends>jboss:service=Naming</depends>
                 <depends>jboss:service=TransactionManager</depends>
                
                 <!--
                 Configure the TransactionManager
                 -->
                 <attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute>
                
                 <!--
                 Node locking scheme:
                 OPTIMISTIC
                 PESSIMISTIC (default)
                
                 WARNING: Using node locking scheme of OPTIMISTIC is EXPERIMENTAL at this stage
                 and is not officially released or supported.
                
                 -->
                 <attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
                
                
                 <!--
                 Isolation level : SERIALIZABLE
                 REPEATABLE_READ (default)
                 READ_COMMITTED
                 READ_UNCOMMITTED
                 NONE
                 -->
                 <attribute name="IsolationLevel">READ_COMMITTED</attribute>
                
                 <!--
                 Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
                 -->
                 <attribute name="CacheMode">REPL_SYNC</attribute>
                
                 <attribute name="UseInterceptorMbeans">true</attribute>
                
                 <!--
                 Just used for async repl: use a replication queue
                 -->
                 <attribute name="UseReplQueue">false</attribute>
                
                 <!--
                 Replication interval for replication queue (in ms)
                 -->
                 <attribute name="ReplQueueInterval">0</attribute>
                
                 <!--
                 Max number of elements which trigger replication
                 -->
                 <attribute name="ReplQueueMaxElements">0</attribute>
                
                 <!-- Name of cluster. Needs to be the same for all clusters, in order
                 to find each other
                 -->
                 <attribute name="ClusterName">Prov-Set7</attribute>
                
                 <!-- JGroups protocol stack properties. Can also be a URL,
                 e.g. file:/home/bela/default.xml
                 <attribute name="ClusterProperties"></attribute>
                 -->
                 <!-- Uncomment next three statements to enable JGroups multiplexer.
                 This configuration is dependent on the JGroups multiplexer being
                 registered in an MBean server such as JBossAS. -->
                 <!--
                 <depends>jgroups.mux:name=Multiplexer</depends>
                 <attribute name="MultiplexerService">jgroups.mux:name=Multiplexer</attribute>
                 <attribute name="MultiplexerStack">udp</attribute>
                 -->
                
                 <attribute name="ClusterConfig">
                 <config>
                 <!-- 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="47700"
                 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="192.168.100.8"/>
                 <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" discard_delivered_msgs="true"/>
                 <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"/>
                 </config>
                 </attribute>
                
                
                
                 <attribute name="FetchStateOnStartup">true</attribute>
                 <!--
                 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
                 -->
                 <attribute name="InitialStateRetrievalTimeout">50000</attribute>
                
                 <!--
                 Number of milliseconds to wait until all responses for a
                 synchronous call have been received.
                 -->
                 <attribute name="SyncReplTimeout">100000</attribute>
                
                 <!-- Max number of milliseconds to wait for a lock acquisition -->
                 <attribute name="LockAcquisitionTimeout">150000</attribute>
                
                 <!-- Name of the eviction policy class. Not supported now. -->
                 <attribute name="EvictionPolicyClass"></attribute>
                
                
                
                
                 <!--
                 <attribute name="CacheLoaderClass">org.jboss.cache.loader.bdbje.BdbjeCacheLoader</attribute>
                 <attribute name="CacheLoaderConfig">c:\tmp\bdbje</attribute>
                 <attribute name="CacheLoaderShared">true</attribute>
                 <attribute name="CacheLoaderPreload">/</attribute>
                 -->
                
                <!--
                 <attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute>
                 <attribute name="CacheLoaderConfig">/tmp</attribute>
                 <attribute name="CacheLoaderShared">true</attribute>
                 <attribute name="CacheLoaderPreload">/</attribute>
                -->
                 <attribute name="CacheLoaderConfiguration">
                 <config>
                 <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
                 <passivation>false</passivation>
                 <!-- comma delimited FQNs to preload -->
                 <preload>/</preload>
                 <!-- are the cache loaders shared in a cluster? -->
                 <shared>true</shared>
                
                 <!-- we can now have multiple cache loaders, which get chained -->
                 <!-- the 'cacheloader' element may be repeated -->
                 <cacheloader>
                 <class>org.jboss.cache.loader.JDBCCacheLoader</class>
                 <!-- same as the old CacheLoaderConfig attribute -->
                 <properties>
                 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(500)
                 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:@192.168.100.9:1521:TPFDB
                 cache.jdbc.user=tpf
                 cache.jdbc.password=tpf
                 cache.jdbc.datasource=tpfDBDS
                 </properties>
                 <!-- whether the cache loader writes are asynchronous -->
                 <async>false</async>
                 <!-- 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. -->
                 <fetchPersistentState>true</fetchPersistentState>
                 <!-- determines whether this cache loader ignores writes - defaults to false. -->
                 <ignoreModifications>false</ignoreModifications>
                 <!-- if set to true, purges the contents of this cache loader when the cache starts up.
                 Defaults to false. -->
                 <purgeOnStartup>false</purgeOnStartup>
                 </cacheloader>
                 </config>
                 </attribute>
                
                
                 </mbean>
                
                
                 <!-- Uncomment to get a graphical view of the TreeCache MBean above -->
                 <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">-->
                 <!-- <depends>jboss.cache:service=TreeCache</depends>-->
                 <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>-->
                 <!-- </mbean>-->
                
                
                </server>
                


                • 5. Re: Jdbc Cahce Loader Issue
                  Manik Surtani Master

                  Like I said, try setting fetchPersistentState to false.

                  • 6. Re: Jdbc Cahce Loader Issue
                    Shanthi Shanmugam Newbie

                    Hi ,

                    Thanks for your suggestion. As you said, I have set fetchpersistantstate to FALSE. Now the records are NOT missing in the database during portal startup failure.

                    I want to know by setting fetchpersistentstate to FALSE, will this impact on cache clustering.

                    Please validate my understanding

                    1. I want to know the difference between fetchpersistentstate and fetchinmemorystate.

                    My understanding is below

                    (i). if fetchinmemorystate is TRUE - It acquires the initial state from the existing members in the cluster during startup
                    (ii). if fetchpersistent state is TRUE - Reads the data from database and loads the data into its cache
                    (iii). if fetchinmemorystate is TRUE and if fetchpersistent state is TRUE
                    a.it acquires the persistent state from the existing member in the cluster
                    b.Deletes the record(s) from the DB.
                    c.Persist the data fetched from the existing member in the cluster to DB
                    d.Retrieves the data from DB and reloads the data into its cache

                    Is my understanding on the above flow is correct?

                    2. Can we set both fetchpersistentstate and fetchinmemorystate to TRUE. If we can, please explain how it will work and the need(advantage) behind this setting.

                    3. What is the impact on cache clustering if fetchpersistentstate is set to FALSE?



                    • 8. Re: Jdbc Cahce Loader Issue
                      Manik Surtani Master

                      Hi

                      "shanthi_jbosscache" wrote:

                      1. I want to know the difference between fetchpersistentstate and fetchinmemorystate.

                      My understanding is below

                      (i). if fetchinmemorystate is TRUE - It acquires the initial state from the existing members in the cluster during startup


                      Correct, but only from the in-memory state of neighbouring caches.

                      "shanthi_jbosscache" wrote:

                      (ii). if fetchpersistent state is TRUE - Reads the data from database and loads the data into its cache


                      Wrong. If fetchPersistentState is true, then state is retrieved from the persistent state of neighbouring caches.

                      "shanthi_jbosscache" wrote:

                      (iii). if fetchinmemorystate is TRUE and if fetchpersistent state is TRUE
                      a.it acquires the persistent state from the existing member in the cluster
                      b.Deletes the record(s) from the DB.
                      c.Persist the data fetched from the existing member in the cluster to DB
                      d.Retrieves the data from DB and reloads the data into its cache


                      Correct.


                      "shanthi_jbosscache" wrote:

                      2. Can we set both fetchpersistentstate and fetchinmemorystate to TRUE. If we can, please explain how it will work and the need(advantage) behind this setting.


                      You can do this if you don't have a shared cache loader, but instead configure each cache instance with it's own standalone cache loader, e.g., on a file system. This can help by loading up-to-date state from neighbouring caches' cache loaders in case your "persistent" state becomes out of date.

                      "shanthi_jbosscache" wrote:

                      3. What is the impact on cache clustering if fetchpersistentstate is set to FALSE?


                      No negative impact at all since your cache loader is *shared* between all cache instances!

                      HTH,
                      Manik