In our ejbLoad we are all accustomed to calling:
PK key = (PK)this.entityContext.getPrimaryKey();
We do this because the bean's attributes are not yet set and the container will
use the entitycontext to pass the pk.
In ejbRemove(), we do not have to resort to this step because the bean's
attributes will be set with a call to ejbLoad() in the case of commit options B
and C.
But how do we execute ejbRemove() when using commit option A? When using commit
option A, the bean is *not* synced with the db because ejbLoad() does not fire.
The container however must ensure that you get the appropriate bean instance
that matches the PK you wish. So if I do:
MyRemote remote = getMyHome().findByPrimaryKey(pk);
remote.remove();
the FBPK method should return a remote reference to the bean in the ready pool
that matches the pk value I pass in, if it exists already. If it does, ejbLoad()
is not called. However, when I invoke remote.remove(), the pk attribute of the
bean is null!? This appears to be a bug.
jim
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
