BEA notes:

DStore more interesting b/c it handles multiple writers correctly so you can do Web Services conversation state.  (aka "workflow").  Some workflow state only has coarse-grained multiple writers, then you can put it in SSM or a db.  Some has fine-grained multiple writers, then use DStore.

Win from DStore: you can do write-behind on disk (async writes) but get most of the guarantees of sync writes.

Session state: durabbility we have may be more than is needed.  Could also architevturally collapse bricks into appserver tier, then it's like BEA's system but with different strategy for replication and failover.

Apples-to-apples comparison: how much thruput is lost from the appserver's pt of view with SSM, compared to doing in-memory-only on a single node?  (BEA is interested in how much thruput is lost because of the extra replication; claims most customers don't want more reliabilty for session state but do want more thruput.

When would redeploying ejb's actually help?  what kinds of failures, and what is being done to scrub state etc after the redeploy?

----

Possible project: use AOP to do to Weblogic what we did to JBoss.  They'd give us object code for Weblogic, their internal test app (MedRec, which would have to be ported to Jboss if we wanted to use it there...), and we'd try to replicate the JAGR/SOSP paper results

Interested in a summer (or AY) intern to work on:  AOP for adding recovery to weblogic; Pinpoint stuff applied to Weblogic;  possibly something about state replication and how it could be used for workflow mgt, etc.