Head First EJB

Entities vs. Entity Beans

An entity is the real thing that the entity bean represents. It doesn’t work in reverse! The entity does not represent the entity bean. That might seem like a subtle point, but it’s not. The difference is in knowing which one is real, and which one is simply a view of the real thing.

In other words, if you delete the real entity (the thing) in the database, the entity bean disintegrates. Poof. But if the entity bean dies, as an instance on the heap, it doesn’t kill the real entity in the database. (By the way, we’re now going to say ‘database’ instead of ‘underlying persistent store’, but you and I both know that these two are not necessarily synonymous, and that the ‘underlying persistent store’ need not be—but usually is—a database. There, we’ve said it.)

So you won’t have the right perspective if you think of the entity bean as some data object that happens to be backed up to persistent storage. In nearly all applications, the vast majority of entities used in the app are not realized as entity beans at any given time. Instead, most entity beans become a representation of an underlying entity only when that particular entity is needed in the application logic.

For example, imagine your database has 10,000 customers. But at any given time, clients (through business processes in session beans) are using only 200 of those customers. In that case, you probably have only 200 entity beans actively representing customer entities. The rest of the 9,800 customer ...