[jboss-jira] [JBoss JIRA] Updated: (JBAS-3772) JBossCache classes fail serialization compatibility tests

JBossCache classes fail serialization compatibility tests --------------------------------------------------------- Key: JBAS-3772 URL: http://jira.jboss.com/jira/browse/JBAS-3772 Project: JBoss Application Server Issue Type: Bug Security Level: Public(Everyone can see) Components: Clustering Reporter: Ryan Campbell Assigned To: Brian Stansberry Fix For: JBossAS-4.0.5.GA The serialVersionUID's changed for the following classes between JBoss 4.0.4 & JBoss 4.0.5: serialVersionUID error for org.jboss.cache.OptimisticTreeNode, 404 -5988969949899616983, current: 7000622696587912654 serialVersionUID error for org.jboss.cache.ReplicationException, 404 1652498986885131620, current: -2141504272926290430 Impact: The following are the scenarios where ReplicationException would be thrown and thereafter could be serialized. None of the following affect the primary use of JBC in 4.0.x, which is for HttpSession replication. 1) Cache A tries to replicate to Cache B. REPL_SYNC. Replication fails because B is suspected at the JGroups layer, or because B doesn't reply before the configured timeout. Cache A will throw ReplicationException which will propagate out of the cache and into caller code. If that caller code then serializes the exception to a JVM with a different JBC version on the classpath, you have a problem. Note that ReplicationException won't be thrown with REPL_ASYNC, so not an issue there. The likely caller code for that kind of scenario would be an EJB with a remote client. EJB2 containers don't use JBC themselves; it would have to be a session bean impl using JBC. EJB3 containers do use JBC directly. The integration layer (StatefulTreeCache) will wrap the ReplicationException in RuntimeException and rethrow it. It will then propagate to the client. This would require standardizing on JBC 1.4.0.SP1. This would usually only be a problem with a client in a 3rd JVM, not part of the cluster, because EJB calls originating on a node in the cluster are going to be made locally. 2) REPL_SYNC. Cache A replicates a list of changes to Cache B as part of a prepare() call (during tx commit). B starts a local tx to apply the changes. During the course of applying the changes the local tx gets marked rollback only. B will detect this and throw a ReplicationException which will be serialized and returned to A. This is an obscure case. The JBC code itself won't ever mark the tx rollback only. User code would have to implement TreeCacheListener and do something to access the tx context. A contrived example of how this could happen would be a TreeCacheListener that calls into a CMT REQUIRES session bean. The local tx would propagate and could be marked for rollback. Not a common scenario. 3) OPTIMISTIC_SYNC. Same as #2, but optimistic locking was just an unsupported beta feature in 1.2.4.SP2, so backwards compatibility is not supported.