When using container-managed persistence, the container does all the work.
The instance variables of the bean instance are mapped indirectly through the container to the underlying persistent data.
This mapping occurs outside the bean. The bean knows nothing at all about this process. This makes the bean very portable as it contains no specialized knowledge.
The instance variables must be declared public so the container can read and write them.
The following diagram illustrates the mechanism of container-managed persistence:
How it works
Synchronize Data
When the container needs to synchronize the data in the bean instance with the underlying persistent data,
it copies the data out of the instance and into a buffer in the container.
The container then writes the data out to the database or databases, as the case may be.
Loading the data is simply the reverse.
Object Relational Mapping and other Schemes
You will appreciate that the view of the data from within the bean may be very different from the actual location, format, and structure of the underlying data. The container maps the data in the bean to the persistent store in some manner that is convenient. For example, the container may support object to relational mapping or some other technique. The bean is portable, as there is a de-coupling between the data representation in the bean, and that in the container.
Primary keys
Entity beans that use container-managed persistence still support the idea of a primary key.
The only difference is that the container uses the primary key directly rather than invoking the ejbLoad() method on the bean.
It extracts the primary key from the variables that make up the primary key.
This subject will be covered in greater detail later. The next lesson introduces the lifecycle of the entity bean.