[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