-
1. Re: Redeployment issues
norbert Aug 31, 2004 9:45 AM (in response to lakr1)this is due to the fact that objects in the cache that is residing in the same JVM as the ejb are accessed by reference without any check whether the previous loaded classes of these objects are accessible to the current ejb's classloader anymore. This isn't easy to solve as long the objects themselve are stored in the cache and not externalized or serialized versions of them.
I'd expect you would get the same error if you deploy two ejbs accessing the same instance of TreeCache from 2 different ears using classes that are both loaded by the different classloaders of the 2 applications.
Flushing the local cache on undeployment of the ejb is not a solution, since this might lead to totally unexpected behavior (as it makes a difference wheter another member in the group is active until the ejb is redeployed which would allow to refetch the state.)
As a workaround you may include the classes in the servers classpath, so the classes do not have to be reloaded. Maybe this is the only suitable solution as long we agree that it's desirable to allow a per-JVM shared cache at all. -
2. Re: Redeployment issues
ben.wang Aug 31, 2004 10:03 AM (in response to lakr1)This classloading issue is also disucssed here:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3842379
There is really no good (optimized) solution to it except to have another in-vm cache per ejb app.
I have also put it under the latest FAQ. Check it out.
-Ben -
3. Re: Redeployment issues
lakr1 Sep 2, 2004 2:59 AM (in response to lakr1)Hello,
Does the MarshalledValue solution implie that my POJO will be serialized on put and deserialized on get. If that is true, it would seriously degrade the perfomance as I cache quite large objects.
Norbert: As a workaround you may include the classes in the servers classpath, so the classes do not have to be reloaded.
That would mean that the those classes cannot be hotdeployed at all!
Norbert: I'd expect you would get the same error if you deploy two ejbs accessing the same instance of TreeCache from 2 different ears using classes that are both loaded by the different classloaders of the 2 applications.
Yes I get the same error.
// Lars -
4. Re: Redeployment issues
norbert Sep 2, 2004 6:17 AM (in response to lakr1)>Does the MarshalledValue solution implie that my >POJO will be serialized on put and deserialized on >get. If that is true, it would seriously degrade the >perfomance as I cache quite large objects.
correct. That's why storing references to the actuall object itself is choosen for the local cache.
>Norbert: As a workaround you may include the >classes in the servers classpath, so the classes do >not have to be reloaded.
>That would mean that the those classes cannot be >hotdeployed at all!
also correct.
As you might see there is no way to have both:
Store references to object instances and access them later while having the classes (that might have changed in the meantime) redeployed will never work. -
5. Re: Redeployment issues
ben.wang Sep 2, 2004 8:41 AM (in response to lakr1)I have also put a faq on class loading scope regarding to JBossCache (and caching system, in general, AFAIK). Here is the url:
http://docs.jboss.org/jbcache/FAQ.html
-Ben -
6. Re: Redeployment issues
tomerbd2 Jun 12, 2007 3:04 AM (in response to lakr1)Hi,
I'm having the same problem described in this thread and using MarshaledValue solved my problem, however as described, this solution is having a performance penalty, so I would prefer not to use it.
Its written in the thread that:There is really no good (optimized) solution to it except to have another in-vm cache per ejb app.
What is an in-vm cache per ejb app?
How can I implement such a solution?
Thanks -
7. Re: Redeployment issues
brian.stansberry Jun 12, 2007 9:55 AM (in response to lakr1)Have a look at the region-based marshalling feature discussed at http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.0/TreeCache/en/html/treecache_marshaller.html.
Basically allows you to register a classloader with region of the cache. Simplified usage:
On deploy of your app:
1) register a classloader with the region of your cache where you will store objects for that app.
2) activate that region
On undeploy of your app:
3) Inactivate the region
4) Unregister the classloader