I'm not shooting that high. The cache that I have in mind should not do much besides replicating its data (doesn't apply for the local cache), and acquiring the cache state from othes in the cluster when coming up.
This will be an MBean. Note that I'm not even mentioning entity beans at this point: the cache is J2EE agnostic.
We can then go ahead and create more elaborate caches, which use the simple functionality offered by the cache. What you described could very well be implemented with this simple cache.
This simple cache already exists (org.javagroups.blocks.TransactionalHashtable), but I have to port it to JBoss first, and work on the locking stuff. The hooks are in place, but not yet the implementation.
Note that if the number of clients or if the number of update is high, this kind of optimisation will not scale.
Maybe you are trying to mimic a 2-tiers system in a n-tiers environment. Why not let the app servers do the caching on the app server side and have the client request information. For client-specific beans (such as SFSB), then yes, it is possible to do client-side caching (in the proxy) or, if the client manages the transaction, we could also do that for some entity beans. Nevertheless, the client will, in most cases, never directly access entity beans remotly.