5 Replies Latest reply on Sep 9, 2008 1:27 PM by Jorge Morales

    Custom Eviction Policy and JDBC Cache loader

    Jorge Morales Master

      I want to achive this behaviour:


      Have a cache with a JDBCCacheLoade for secondary storage
      Have some regions configured to evict nodes, and some to remove
      Only have in secondary storage nodes being evicted, once, and only once, they have been evicted


      For this, I have done a custom eviction Policy to remove data from cache, as related in here. I have configured a default eviction Policy for the cache, and region eviction policies for different regions, if they have to bee persisted with a normal eviction policy, if they have to be removed with a custom remove policy.
      What I experience is that my data is being written to secondary storage as soon as I write into cache, and once the eviction work runs, it removes data from database that has the custom remove policy.

      Question is:

      How can I configure caches, to only persist when eviction policy is run?

      Cache version is a custom patched JBC1.4.1.SP9.

      Here is my config.

      <server>
       <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" />
      
       <mbean code="com.xxx.cache.core.mbean.ServiceDataCacheWithListener"
       name="jboss.cache:service=XXXServicesDataCache">
      
       <depends>jboss:service=Naming</depends>
       <depends>
       jboss.jca:name=jdbc/somservices,service=DataSourceBinding
       </depends>
       <attribute name="IsolationLevel">NONE</attribute>
       <attribute name="CacheMode">REPL_ASYNC</attribute>
       <attribute name="UseReplQueue">false</attribute>
       <attribute name="ReplQueueInterval">0</attribute>
       <attribute name="ReplQueueMaxElements">0</attribute>
       <attribute name="ClusterName">
       SOMServicesCache-Cluster
       </attribute>
       <attribute name="ClusterProperties">file:///opt/cache-config.xml</attribute>
       <attribute name="FetchInMemoryState">${cache.service-data.fetch-in-memory:true}</attribute>
       <attribute name="InitialStateRetrievalTimeout">${cache.service-data.state-retrieval-timeout:15000}</attribute>
       <attribute name="SyncReplTimeout">2000</attribute>
       <attribute name="LockAcquisitionTimeout">10000</attribute>
       <attribute name="EvictionPolicyClass">
       org.jboss.cache.eviction.LRUPolicy
       </attribute>
       <attribute name="EvictionPolicyConfig">
       <config>
       <attribute name="wakeUpIntervalSeconds">30</attribute>
       <region name="/_default_">
       <attribute name="maxNodes">100000</attribute>
       <attribute name="timeToLiveSeconds">86400</attribute>
       </region>
       </config>
       </attribute>
       <attribute name="UseRegionBasedMarshalling">true</attribute>
       <attribute name="InactiveOnStartup">false</attribute>
       <attribute name="CacheLoaderConfiguration">
       <config>
       <passivation>false</passivation>
       <preload>/</preload>
       <shared>true</shared>
       <cacheloader>
       <class>
       org.jboss.cache.loader.ClusteredCacheLoader
       </class>
       <properties>timeout=30000</properties>
       <async>true</async>
       <fetchPersistentState>false</fetchPersistentState>
       <ignoreModifications>false</ignoreModifications>
       </cacheloader>
       <cacheloader>
       <class>org.jboss.cache.loader.MyJDBCTimestampCacheLoader</class>
       <properties>
       cache.jdbc.datasource=java:jdbc/services
       cache.jdbc.table.name=service_data
       cache.jdbc.table.create=true
       cache.jdbc.table.drop=false
       cache.jdbc.table.primarykey=service_data_pk
       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.timestamp.column=timestamp
       cache.jdbc.timestamp.type=timestamp
       </properties>
       <async>true</async>
       <fetchPersistentState>true</fetchPersistentState>
       <ignoreModifications>false</ignoreModifications>
       </cacheloader>
       </config>
       </attribute>
       </mbean>
      </server>
      


        • 1. Re: Custom Eviction Policy and JDBC Cache loader
          Mircea Markus Master

           

          For this, I have done a custom eviction Policy to remove data from cache, as related in here.

          JBC3.0 solves this problem much nicely: you are allowd to specify an EvictionActionPolicy for each evcition algorithm. EvictionActionPolicy refers to allowing one to do to-disk eviction, remove from memory or whatever strategy is chosen.
          What I experience is that my data is being written to secondary storage as soon as I write into cache

          I guess what you need here is passivation:
          <passivation>false</passivation>

          Take a look at what passivation can do for you in the user guide.
          and once the eviction work runs, it removes data from database that has the custom remove policy.

          That is because when you do cache.remove within your custom eviction, this will go through the interceptor chain and remove data from DB, as per a normal cache.remove. Again, passivation should solve this issue for you.

          • 2. Re: Custom Eviction Policy and JDBC Cache loader
            Jorge Morales Master

            I have already tried with passivation, and this seems to be what I was looking for.
            In a clustered environment, how does passivation works? Is there a master cache doing the passivation, or every cache will passivate its data whenever an evict event is triggered?

            The problem with JBC3.x is what we have longely talked in the forums. Not usable with JBossAS4.2.x. :-(

            Thanks Mircea.

            • 3. Re: Custom Eviction Policy and JDBC Cache loader
              Mircea Markus Master

               

              In a clustered environment, how does passivation works? Is there a master cache doing the passivation, or every cache will passivate its data whenever an evict event is triggered?

              no passivation coordinator, pasivation is handled at a node instance and from this POV works like 'classic' cache loading. The only difference stays in *when* the store is touched(e.g. won't store data on cache.put, but only on evict). Documentation :)

              • 4. Re: Custom Eviction Policy and JDBC Cache loader
                Elias Ross Master

                For JBC 1.4 (used in JBoss 4.2), you can still write a custom eviction policy that does a remove. Extend the existing EvictionPolicy-implementing class and override the "public void evict(Fqn fqn)" method.