EJB Entity Beans

Entity Beans Data versus logic Used to represent an instance rather than a collection of data (depending on underlying storage) Represents –a row in a table –an object instance in a OO database

Example Examples –Student in the class –Customer –Ingredients in a recipe Other criteria –must have a unique primary key

Figure 5.1

Figure 5.2

Managing Entity Beans When client needs access, loaded into the application container At appropriate time, the bean in written back to permanent storage Two strategies –container managed –bean-managed

Call backs –EJBStore() called by container when data needs to be persisted –EJBLoad() called by container when data needs to be retrieved How often to refresh/recall is a little complicated –related to transactional state Managing Entity Beans (ctd)

Called by container not client

How many instances? If only one instance, all clients end up being lock-stepped. If more than one instance of a bean (row), one per client, you run the risk of corruption due to race conditions. Give the management to the container Let container use call-backs to keep the bean consistent across all instances(clients)

Other things to save Data is saved/restored via ejbLoad() and ejbStore() Other items such as socket connections define the state of the bean and need to be stored. These non-data items like socket/file connections are managed via ejbPassivate() and ejbActivate() One doesn’t necessarily dictate the other

Other things to save (ctd) Assume a socket connection is part of the bean. Another client updates a property. Container may need to update bean but socket may not need to be opened or closed. Similarly closing a socket doesn’t imply the need to store bean data.

Steps in creating an Entity Bean Access home interface Client calls create() which is like the constructor function. Container calls ejbCreate(). Each client has a separate bean synchronized by container. Bean returns primary key Container creates EJBobject and returns to creator the remote interface to use

Removal Use either home OR remote interface

Bean vs Container Managed Persistence Who writes the code to store the date to permanent storage. Container can manage it. My guess is that eventually the container managed persistence will dominate because it is less work Bean managed allows you to write to whatever store you want-> more flexibility -> more work

getPrimaryKey() Gives a bean a means to figure out which key IT is. Why wouldn’t it know? Could have been activated with a new key For ejbStore it would know “who” it is For ejbLoad it wouldn’t. ejbRemove() should check first in the event that it has been activated with a new key

Code

All Entity Beans must create these. Others for create and findmay apply also.

Implementation Guidelines Entity Beans

Finder Methods

Bean Managed Persistence Bank Account Example

THE Bean Bean-managed State Fields Business Logic Methods EJB required methods

Home<> (static-like) procedure Note: home interface is GetTotalBankValue()

EJB Entity Bean Implementation (things to note) ejbRemove() calls getPrimaryKey() ejbHomeGetTotalBankValue() illustrates how to use JDBC calls and a result set even though this result set has a single member (because of use of sum()) ejbCreate() and use of PreparedStatement ejbFindByOwnerName(..) returns Collection

EJB Entity Bean Implementation (ctd) Note the AccountBean() constructor –no parameters –used when Bean created by container, no key at this point Keys defined on ejbCreate() or ejbLoad(); ejbCreate() has parameters

Client Code (note) Home.getTotalBankValue(); findByOwnerName() returns Collection which can apparently be used to initialize an iterator. Calls home.create(id,owner) to get ejbCreate()

Entity Bean Life Cycle