This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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
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="http://www.orderware.net" target="_blank" rel="nofollow">http://www.orderware.net</a>
Joined: Jul 14, 2001
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’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com