Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Field initialization

 
Sander Fieten
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
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?
greetings
Sander
 
Karl Laird
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Karl Laird
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic