I am confused as to whether Entity beans can cache data between transactions, and hence avoid the overhead of subsequent ejbLOAD() calls.
1) I realise that many application servers seem to offer this functionality as long as the application server has exclusive access to this data.
BUT, does the EJB Specification deal with caching, or is this application server specific?
2) I have also heard the rumour that EJB 2.0 CMP does dealk with Entity Bean caching between transactions - Is this true?
The EJB specification itself is mostly silent about how caching should be handled. In theory, those details are server-specific.
In practice, there are some common caching behaviors in most EJB servers. The exclusive access feature you mentioned is one. Another is data caching within transactions. As a rule, the ejbLoad() method for an Entity bean will be invoked at most once in a given transaction, even if the EJB is used several times in the transaction [ditto for ejbStore()].
"10.5.9 Commit options" chapter can explain some options for caching data.
If we consider categories of data in clustered AS:
cached replicated, flush on update
Read Write with high concurrency
What should be here? I have not found transactional distributed CMP cache in any AS(Could be WLS with optimistic locking? - will be too many optimistic collisions). Should we read from db on every start of transaction?
If you're working with EJB 2.0 compliant appserver, see paragraph 10.5.9 (Commit options) in the specs. With commit option A, you can cache between transactions. Of course, this applies only to CMP - using BPM you must implement caching by yourself.