Head First EJB

The only question is WHO does the work when it’s time to synchronize

The Container always knows when the bean and the database entity must be synchronized. It knows based on transactions. If a client calls a method on a bean, and that method starts a new transaction for the bean, the Container knows that the underlying entity in the database may have changed since the last time this bean was loaded up with this entity’s data. So the Container forces the bean to refresh its state by loading in the entity’s data.

And of course the reverse is true. If the bean completes a method, and this method was the end of the transaction, the Container will tell the database to release the lock on this entity in the database. But... during the time when the row was locked, the bean might have been happily caching data that represents the newly-changed state of the entity (like a new address or phone number). In other words, the client might have been calling setter methods on the bean, with the intention of causing an update in the real database. The client wants to update a record. So, the Container knows it must force the bean to update the data in the database with the bean’s state, before the Container tells the database to release the lock on that entity.

OK, so the when is not the issue. And that’s important, because otherwise you, the Bean Provider, would have to work out the business logic to know exactly when there was a danger that the bean and entity are out of sync. And you can just ...