CMP Entity Beans read database row twice?

Question

Here are two basic questions regarding container managed persistence Entity Beans:
How many database read operations are performed when a remote reference to a CMP Entity Bean is obtained by a client?
Is it correct, that each row is read twice?
For example if a have one row in a database which I want to lookup, AFAIK first the findByPrimaryKey method perfoms a select to lookup the primary key, and then the (container-)ejbLoad method actually reads the row a second time to populate the CMP fields of the bean.
And how often are UPDATE statements performed?
Is a database UPDATE statement performed each time a setXX method is invoked?
Thanks for any help,
Robert

Answer 1

How many database read operations are performed when a
remote reference to a CMP Entity Bean is obtained by a
client?
Is it correct, that each row is read twice?It all depends on the CMP system. A simple system might well hit the database twice, once to validate the primary key and once to load the object's fields. A
smarter system might try to cache the results from the first, so it didn't need to do the second (although this might be a bit dodgy from a transactional point of view).
However, a couple of facts about databases come in here. Firstly, the query to check the primary key doesn't actually need to load any data from the table: it just needs to check that the key exists. Thus, it should be possible to handle this query just using the index, not touching the table itself at all. Secondly, databases do their own caching, so if a row was loaded in the first query, there is a good chance that it would still be around for the second.
And how often are UPDATE statements performed?
Is a database UPDATE statement performed each time a
setXX method is invoked?Under CMP 1.1, UPDATES are typically done at the end of a transaction; if you use container-demarcated transactions, then yes, UPDATES will happen after every call. If the client code sets up its own transaction, then the UPDATE will only happen after several setXXX calls.
This can be a performance problem. A common solution is the use of coarse-grained detail objects:
http://java.sun.com/j2ee/blueprints/sample_application/model/ (section 10.4.1.2)