Hi,
the CVS version (pre2.1) of CMPPersistenceManager should initialize the CMP
fields to Java default values before calling ejbCreate() method. I have not
tested this though.
Anyhow, it seems to be a requirement for the PM to do this in EJB 2.0
according to the latest public draft... we'll see if it sticks.
-- Juha
At 19:18 2.3.2001 -0500, you wrote:
>|The odd behavior I've noticed is that when create() is invoked on an
>|Entity's EJB home, data fields that are not initialized in the
>|corresponding
>|ejbCreate() method in the implementation class are being populated with
>|(cached ??) data from the most recently activated (i.e., via a
>|findByPrimaryKey() ) Entity bean instance of the same type.
>|
>|Does anyone have a definitive answer as to why this happens?
>
>well a "create" will take an instance from the pool. We do not clean
>instances as we rely on "ejbLoad" mechanisms to set the fields. It is then
>possible that if your business methods operate on fields that are not
>affected by the create() that you would find "melted cheese" data from a
>previous identity the bean instance assumed. I am working from memory (I
>haven't read the spec in a looong time) but I don't recall any cleaning
>falling to be done for entities by the container other than the ejbLoad.
>
>I assume it is up to you to code your create to actually set the fields to
>zero. If you so wanted you could also code the pool to set the fields to
>the null values upon returning. That would be simple enough to extend from
>the existing pools.
>
>That being said I do believe that create() and ejbLoad() should essentially
>work on ALL the fields and I would be curious to see that the spec requires
>that you work on ALL the fields (as opposed to a subset like you are
>indicating)
>
>As far as why it is the "most recently" activated that is assigned. I
>believe this statement to be partially true only, it would probably be the
>most recently activated and returned to the pool which would indicate that
>our pools are stack based (which I believe they are) so it would make sense.
>
>marc
>
>|
>|
>|joe
>|
>|
>|
>|>>>>> "Joe" == Joe Barefoot <[EMAIL PROTECTED]> writes:
>|
>| Joe> I don't have a definite answer for this odd behavior, but I've
>| Joe> noticed the same thing. This seems to happen anytime you don't
>| Joe> initialize the data fields of your entity bean in the ejbCreate()
>| Joe> method.
>|
>|It is my underdanding that entity and stateful session bean
>|objects are kept
>|in a pool that the container swaps data into on demand by calling ejbLoad
>|for
>|performance rather than creating new object everytime. What are those
>|states
>|again? Pooled -> Ready, and so on.
>|
>|
>|--
>|--------------------------------------------------------------
>|To subscribe: [EMAIL PROTECTED]
>|To unsubscribe: [EMAIL PROTECTED]
>|
>|
>|
>|--
>|--------------------------------------------------------------
>|To subscribe: [EMAIL PROTECTED]
>|To unsubscribe: [EMAIL PROTECTED]
>|
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
