- Overview
- The javax.ejb Package for Entity Beans
- Entity Bean Types
- Remote Versus Local Interfaces
- BMP Entity Bean Lifecycle
- Specifying a BMP Entity Bean
- Implementing a BMP Entity Bean
- Configuring and Deploying a BMP Entity Bean
- Client's View
- Session Beans Revisited
- Patterns and Idioms
- Gotchas
- Summary
- Q&A
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
Gotchas
The following is a quick checklist of "gotchas" to help you with your implementation:
Primary keys must be immutable. In other words, it is not possible to change the value of a primary key for an entity once assigned (see EJB specification, section 10.3.5).
Of course, there is nothing to prevent you from directly changing the data in the underlying persistent data store (for example, with an SQL UPDATE statement). But you will need to do this with the EJB container offline or otherwise at rest.
Sometimes, Entity beans interact with non-data store resources. An example might be a client java.net.Socket or perhaps a subscription to a JMS topic (covered more on Days 9, "Java Messaging Service," and Day 10, "Message-Driven Beans"). These resources will need to be acquired in both ejbActivate() (for an existing bean) and also for ejbCreate() (if the bean has just been created).
Similarly, resources should be released in both ejbPassivate() and ejbRemove(). This is because a bean being deleted will not be passivated first.
Finder methods can return Collections, but they can't return Lists, Sets, or Maps. However, this capability is planned for future versions of the EJB specification.
If you have two bean references, note that the value of bean1.equals(bean2) is unspecified, and that bean1 == bean2 is also unspecified. Moreover, hashCode() may differ for two references to the same underlying EJB. (All of these points are made in the EJB specification, section 9.8.)
The correct way to compare bean identity is to use bean.isIdentical() or to use the equals() method on the primary key classes.
Beware of a reliance on pass-by-reference side-effects when using local interfaces. Such a reliance would compromise portability.