Session Beans Versus Entity Beans in Java

Creator QR-Code in Java Session Beans Versus Entity Beans

The fact that we are now accessing Web pages by using entity beans, which we did in 29 by using session beans, might seem a bit confusing After all, session beans and entity beans are supposed to be conceptually different This is true, but choosing the best type of bean depends on the application requirements that the EJB need to address The session beans in 29 were used to reduce the amount of network traffic Consider a more sophisticated application in which you would like to cache the content of the page to allow offline Web browsing on the client side In other words, you would like the client to download the current copy of the page (actually copies of a set of pages) and later request updates from the server In this case, the server would need to be aware of the most recent copy of the data held at the client side to determine what pages were updated Furthermore, this process might span a prolonged period of time, much longer than a typical "session" Therefore, entity beans would be the best choice for this application The immediate benefit of implementing our bean as an entity bean is its persistence and, consequentially, its ability to withstand server failures Entity beans differ from session beans in several ways One critical difference is that with state-ful session beans, the client that created the bean is typically the sole user of the bean With entity beans, a bean can be created by one client and used by another client Clearly, this functionality is an important one that enables entity beans to be used as business objects representing business data stored in a database The entity bean model has built-in support for using beans created by other clients, in that entity beans can be "found" using a finder method Using such a method makes it possible to look up a specific entity bean and access it To implement this functionality, entity beans have keys associated with them (More on keys in the next section) Another interesting difference between session beans and entity beans is that the latter are potentially subject to modification that is external to the EJB architecture Because persistence is typically achieved by means of a relational database, changes to the data stored in the database would imply that entity beans are changed when they are accessed by client-side code In fact, you could say that entity beans provide a different "view" into the relational database Of course, entity beans provide much more than that, as they encapsulate complex business logic Another difference between session beans and entity beans is in their lifecycles; and this difference is due to the fact that session beans are persistent Session beans have a limited life span and are typically destroyed after a certain time In contrast, entity beans have longer time spans and are destroyed only upon an explicit invocation of the remove method on either the remote interface or the home interface Note that, in other ways, entity beans behave like session beans For example, like stateless session beans, entity bean instances are pooled; the same in-memory object can be used for several bean objects 524

The EJB context is different for entity beans and session beans Recall from 11 that the EJB context object informs the bean about the surrounding environment For entity beans, the bean context adds two new methods, getEJBObject and getPrimaryKey The getEJBObject method also exists for session beans, and it allows the bean implementation to obtain a reference to a "remote" interface to itself, so in some sense it is the remote version of the this object in Java The getPrimaryKey method allows the bean to get its own primary key While that might not make a lot of sense at first glance, it is necessary because bean instances are pooled and reused Whenever an entity bean needs to find out what its primary key is (especially in the ejbLoad, ejbStore, and ejbRemove methods), the prudent way to find it is by using getPrimaryKey