Thanks, Max.
I figured if update timestamps was replicated it should be OK. I'll of course test it
out :).
anonymous wrote :
| Saying that, I'm surprised to hear that JBC isn't able to use the applications
current thread context classloader ?! I thought this were the way these serilaization
issues were solved before ?
|
Problem arises because the cache is not deployed as part of the application -- it's a
shared resource. Deserialization is done by a thread coming up from the JGroups layer,
not an "application" thread, so there is no single correct TCCL to use.
But, you raise an interesting point about when the cache is not a shared resource. In
that case it still uses the classloader that loaded JGroups to deserialize messages,
rather than the TCCL that was in effect when the cache was deployed. I'll open a forum
thread about that.
anonymous wrote :
| Note, I don't think the serialization issues only occur for querycache - it would
AFAIK also occur if a user has his own UserType in the id of his entities.
|
Yep. That requires JBCACHE-876 to fix, since the user class will be in the Fqn rather than
the data map. :(
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989409#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...