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