[jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1039) Optimized replication of entities and extended persistence context in SFSBs

Optimized replication of entities and extended persistence context in SFSBs --------------------------------------------------------------------------- Key: EJBTHREE-1039 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1039 Project: EJB 3.0 Issue Type: Feature Request Components: Clustering Reporter: Brian Stansberry Assigned To: Paul Ferraro Optimize replication of clustered SFSBs that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held by the SFSB and those held by the replicated EntityManager. Currently object identity is maintained by serializing the SFSB and the related EntityManager in one operation. The entire EM is serialized, including entities that have been flushed to the db. This is inefficient, since the replication is only done to support failover and in the case of node failover, the flushed entities can be restored from the db or the EM's 2nd level cache. Intent is to: 1) Use JBoss serialization in order to have the ability to alter the serialized form of entities and XPCs. 1) Have Hibernate's EM impl expose getUnflushedChanges()/setUnflushedChanges() methods to support replication of only the unflushed changes held in the XPC, rather than all data. 2) When writing the fields in an SFSB, check if the object is a managed entity; if so write it's id to the stream rather than the whole object. 3) Deserialization process needs to ensure that any EntityManager is deserialized before the managed entities. 4) Deserialization of a managed entity would involve reading the id from the stream, identifying the EntityManager and doing a find(). 5) SFSBs should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way SFSBs clustering already works. This is critical, otherwise the cost of the find() operations would likely outweigh the benefits of reducing the amount of replicated data. Additionally, intent is to allow registration with the container of an impl, say, "ManagedPersistenceContextSerializer". If registered, implementation of many of the steps above would be delegated. JBoss Seam would intend to register an implementation.