Optimized replication of entities and extended persistence context in HttpSessions ---------------------------------------------------------------------------------- Key: JBAS-4629 URL: http://jira.jboss.com/jira/browse/JBAS-4629 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Optimize replication of clustered web sessions that hold refs to managed entities and extended persistence contexts, while still ensuring that object identity is maintained between refs to an entity held as a session attribute and those held by the replicated EntityManager. Currently object identity is maintained by serializing the entire session as one operation (and thus only works reliably if SESSION granularity is used). 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 attributes in the session, 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) Sessions should be lazy-deserialized (i.e. only deserialize if needed to handle failover). This is the way web session 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira