Use the following guidelines when designing and developing enterprise beans.
Local calls avoid the overhead of RMI/IIOP and use pass-by-reference semantics instead of pass-by-value. For each call, the caller and callee beans share the state of arguments. EJB 2.x and later beans can have both a local and remote interface, but more typically, have one or the other.
From JDBC 2.0 on, PreparedStatement objects can maintain a list of commands that can be submitted together as a batch. Instead of multiple database round trips, there is only one database round trip for all the batched persistence requests.
You can enable the use of this feature for EJB container managed persistence (CMP). When you do, the run time defers ejbStore/ejbCreate/ejbRemove or the equivalent database persistence requests (insert/update/delete) until they are needed. This can be at the end of the transaction, or when a flush is needed for finders related to this EJB type. When the persistence operation finally happens, run time accumulates the database requests and uses JDBC PreparedStatement batch operation to make a single JDBC call for multiple rows of the same operation.
The product enables you to make the same settings using assembly tools.
For CMP during the ejbCreate, the container can create the representation of the entity in the database immediately, or defer it to a later time.
You can turn this option on from the EJB CMP side. When you choose this option, the runtime defers ejbCreate, or the equivalent database persistence request, until it is needed. This can be at the end of the transaction, or when a flush is needed for finders related to this EJB type. By doing this you can reduce two round trips for the newly created entity (insert and update) to one (insert).
The product enables you to make the same settings using assembly tools. Review the assembly tools information center at http://publib.boulder.ibm.com/infocenter/radhelp/v7r5mbeta/topic/com.ibm.jee5.doc/topics/cejb3.html