Persistence
Whenever an application is manipulating data, one of its considerations is ensuring longevity of the data beyond the immediate operation. Persistence refers to the activity of ensuring that the changes to data are saved appropriately.
Persistence services are what entity beans are all about, so it is important to understand the differences between the two persistence mechanisms these EJBs can use.
One mechanism is container-managed persistence. The goal for the majority of entity beans you deploy should be to use this mode of operation as frequently as possible. By letting the EJB container manage the persistence, all database access and synchronization is automatically handled for you. Because this is achieved using prebuilt and tested container capabilities, you get high quality persistence support without having to implement and test all the associated infrastructure code.
The other mechanism is bean-managed persistence. In this mode you are still using an entity bean, but you also have to code your own data access and synchronization calls. If you decide to use this approach, it is recommended that you use a separate object, typically referred to as a data access object. You would tie the methods in such an object to the ejbLoad/ejbStore methods that exist in the entity bean implementation. This way, when you decide to move to container-managed persistence at a later time, migration becomes much easier because you can just throw away the encapsulated data access object rather than try to pull out code that is potentially scattered throughout your entity bean.
The question arises as to why someone would ever want to use bean-managed persistence. The most common answer is exactly what we just described—namely to allow an easier way to transition from just writing data access code to using full-featured entity beans.
It should also be mentioned that entity beans are not intended to be the answer for every persistence requirement. If you just need simple access calls for data that is not expected to change very often, and you are not really worried about any concurrency issues, then continuing to just write your own data access objects is likely the best way to go. Figure 13-5 shows typical usage of the different approaches just described.
Figure 13-5. Comparison of available persistence options
Transactions and Concurrency
All entity beans make use of container-managed transaction demarcation, which allows for the concurrency features to work properly. As such, any given entity bean instance is available to any number of clients at a time as long as the clients know how to locate it, and they have the proper security clearance.
As with session beans, transactional attributes are set on the methods a client can call to ensure the integrity of the entity bean and the data it persists. For this type of EJB, this includes all of the user-defined methods on both the Home and Remote interfaces. Valid attribute settings are exactly the same as those used for session beans.