You are reporting lots of bugs against 2.0 final - the code base has moved
considerably since then. You really need to get a more recent version.
Tom
On Thu, 8 Mar 2001, James Cook wrote:
> 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]
>
>
--
"If you mess with something for long enough it will break." - Schmidt
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
