Presentation on theme: "EJB Entity Beans. Entity Beans Data versus logic Used to represent an instance rather than a collection of data (depending on underlying storage) Represents."— Presentation transcript:
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)
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
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
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()
Your consent to our cookies if you continue to use this website.