[jboss-cvs] JBossCache/docs/faq/en ...

Galder Zamarreno galder.zamarreno at jboss.com
Wed Nov 29 13:39:16 EST 2006


  User: gzamarreno
  Date: 06/11/29 13:39:16

  Modified:    docs/faq/en  Tag: Branch_JBossCache_1_4_0 master.xml
  Log:
  How to use JBC marshalling to get around redeployment ClassCastExceptions. QA entry added explaining the problem and resolution as well as a unit test emulating redeployment.
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.34.2.9  +49 -0     JBossCache/docs/faq/en/master.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: master.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/faq/en/master.xml,v
  retrieving revision 1.34.2.8
  retrieving revision 1.34.2.9
  diff -u -b -r1.34.2.8 -r1.34.2.9
  --- master.xml	1 Nov 2006 01:58:42 -0000	1.34.2.8
  +++ master.xml	29 Nov 2006 18:39:16 -0000	1.34.2.9
  @@ -38,6 +38,12 @@
            <email>smarlow at novell.com</email>
         </author>
   
  +      <author>
  +         <firstname>Galder</firstname>
  +         <surname>Zamarreño</surname>
  +         <email>galder.zamarreno at jboss.com</email>
  +      </author>
  +
         <abstract>
            <para>This is a compilation of the most frequently asked
               questions about JBoss Cache. Please report any bugs,
  @@ -1134,6 +1140,49 @@
                  </programlisting>
               </answer>
            </qandaentry>
  +
  +         <qandaentry>
  +            <question>
  +               <para>Can I use <literal>useRegionBasedMarshalling</literal> attribute in JBoss Cache in order to get
  +                  around ClassCastExceptions happening when accessing data in the cache that has just been redeployed?
  +               </para>
  +            </question>
  +
  +            <answer>
  +               <para>Yes, you can. Originally, <literal>TreeCache</literal> Marshalling was designed as a
  +                  workaround for those replicated caches that upon state transfer did not have access to the
  +                  classloaders defining the objects in the cache.
  +               </para>
  +
  +               <para>On each deployment, JBoss creates a new classloader per the top level deployment artifact, for
  +                  example an EAR. You also have to bear in mind that a class in an application server is defined not
  +                  only by the class name but also its classloader. So, assuming that the cache is not deployed as part
  +                  of your deployment, you could deploy an application and put instances of classes belonging to this
  +                  deployment inside the cache. If you did a redeployment and try to do a get operation of the data
  +                  previously put, this would result on a ClassCastException. This is because even though the class names
  +                  are the same, the class definitions are not. The current classloader is different to the one when
  +                  the classes were originally put.
  +               </para>
  +
  +               <para>By enabling marshalling, you can control the lifecycle of the data in the cache and if on
  +                  undeployment, you inactivate the region and unregister the classloader that you'd have registered on
  +                  deployment, you'd evict the data in the cache locally. That means that in the next deployment, the
  +                  data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to get
  +                  around this problem is only recommended when you have some kind of persistence backing where the data
  +                  survives, for example using CacheLoaders, or when JBossCache is used as a second level cache in a
  +                  persistence framework.  
  +               </para>
  +
  +               <para>To implement this feature, please follow the instructions indicated in the example located
  +                  in the TreeCacheMarshaller section of the user's guide. It's worth noting that instead of a
  +                  <literal>ServletContextListener</literal>, you could add this code into an <literal>MBean</literal>
  +                  that contained lifecycle methods, such as <literal>start()</literal> and <literal>stop()</literal>.
  +                  The key would be for this MBean to depend on the target cache, so that it can operate as long as the
  +                  cache is up and running.
  +               </para>
  +            </answer>
  +         </qandaentry>
  +
         </qandaset>
      </chapter>
      <chapter
  
  
  



More information about the jboss-cvs-commits mailing list