How does the clustering service state replication deal with transactional integrety? I believe that JBossCache claims to have the cache updates as a part of the transaction, does GFV2 have feature parity here? I believe that it's a critical feature to be able to make real optimizations and reducing DB-load significantly otherwise it's hard to trust the integrity of the data in a fail-over scenario in which case we might have to hit the DB anyways, thereby destroying the value of the session replication.
Here are some thoughts.
For a fully consistent state replication the replication should take place with-in the same transactional scope. 2-phase commit like a normal resource like a DBMS really, but not stored on disk normally.
Overview of how it should work for fully consistent state
1) Transaction starts on node 1
2) application on node 1 updates a state which is replicated to node 2 but marked as "pending commit"
3) Transaction on node 1 completes and the replicated state is "commited" on node 2.
This will of course not be the most highly performant state replication solution but will likely be much better then a DB since it's in-memory.
If we want to compromise on Tx integrity we should be able to configure the state replication to happen asynchronously and sent in "bursts" to the fail-over node or to not have 2-phase commit for commiting the state.
[Message sent by forum member 'jesper_soderlund' (jesper_soderlund)]
http://forums.java.net/jive/thread.jspa?messageID=243071