Sacha raised a good point today re: the need to replicate any SFSB and http session state changes associated with a request at the same time. Otherwise, we just double the replication-related latency of the request. This is critical in the case of SEAM.

A couple of issues immediately come to mind that we need to solve:

1) Transaction demarcation. The tx used for session replication is started and ended outside of user code. A Tomcat valve is used. For FIELD repl, the tx starts on request entry and ends on request exit. (We use a special transaction manager so this tx is isolated from anything done in user code). For SESSION and ATTRIBUTE the tx is started and ended at request exit. If at that point there was already a tx associated with the thread the session replication could participate in that tx, but typically any tx from the webapp itself should be closed by the time the session replication code kicks in.

I assume transactions initiated by SEAM are opened and closed within the webapp code itself.

Potentially a filter could be used by the session repl code instead of a valve. But I can imagine lots of problems with that.

2) The JBossCache used for storing state. Currently there are two distinct caches for SFSB and HttpSession, and thus there will be two distinct replications. We would need to unify these caches.

The issue here is what if there are different cache configs for the two use cases (e.g. READ_UNCOMMITTED for SFSB, REPEATABLE_READ for HttpSession)? The JBC task to give greater importance to a cache Region will be needed here (http://jira.jboss.com/jira/browse/JBCACHE-64).