It's not a secret anymore!
The moose likes EJB and other Java EE Technologies and the fly likes Field initialization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Field initialization" Watch "Field initialization" New topic

Field initialization

Sander Fieten

Joined: Mar 08, 2001
Posts: 13
we have encountered the following behaviour in WebSphere:
We have a CMP entity bean. In its ejbCreate method not all fields are set.
Now we create an instance of this EJB and use setter methods to set fields not set in the ejbCreate method.
When we create a second instance of the EJB the fields not set in the ejbCreate have the values set by the calls to the setter methods of instance one.
It looks like WebSphere caches the enity beans somewhere and mixes the values when not explicitly set. Is this expected behaviour?
Karl Laird
Ranch Hand

Joined: Jul 14, 2001
Posts: 67
Yes - kind of. There is nowhere in the J2EE specification saying what should happen with the fields of an entity bean if they are not explicitly set. This is different to saying that they should be set to the java default (IE 0 for int etc). Also there is no guarantee that the data in an entity bean is cleared when it is returned to the pooled state and then reactivated. So you should always set all fields in the create method - even if it is only to the java default as otherwise you may get transfer from a previous entity bean incarnation

The Eagle sneers at the Peacock<p>Systems Administrator<br />OrderWare Solutions Ltd<br /><a href="" target="_blank" rel="nofollow"></a>
Karl Laird
Ranch Hand

Joined: Jul 14, 2001
Posts: 67
To clarify my reply to your question using your example:
You create the first bean 'obj1'. The fields not initialised in the create are undefined (and could be anything) in both the database and entity bean instance currently representing it.
You call the set methods on the bean instance. All the fields are now synchronised to these values in both the instance and the DB.
The bean instance returns to the pooled state, and may retain these values depending on container implementation.
You create the second bean, and the same instance services the requests. However all the fields are still set from the first bean, so any you do not change will have the values from the first bean.

Hope this helps. There are many caveats like this associated with the pooling and activation of instances, it is highly recommended that you investigate how this works from the EJB spec.
I agree. Here's the link:
subject: Field initialization
It's not a secret anymore!