Change PK of A to 3, then PK of B to 1 then PK of A to 2. This can be over
2 or 3 transactions.
Actually the ejbLoad stuff is a red herring, it is unimportant whether it
gets loaded or not. It is important if it gets passivated or not. That's
the only time the PK can change. If you swap primary keys and don't
passivate the beans then you'll retrieve the wrong bean.
Of course if we were using surrogate keys, generated either by a session
bean or from the database it is unlikely we would ever change the primary
key and so we wouldn't run into this odd little bind. But that's where I
started, not changing the primary key.
Cheers
-----Original Message-----
From: Chaganthi, Madhusudan R. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 2:36 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB 1.1 and change of primary key values
Jay
How can you "subsequently change" without the database throwing an error?
>If I subsequently change these beans so entity A has PK = 2 and entity B
has
>PK = 1 then what happens when the client issues a request for the entity
>bean with PK = 1.
-----Original Message-----
From: Jay Walters [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 2:25 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB 1.1 and change of primary key values
So, let's just follow one more step on "the container should allow me to
change my primary key because it's a good thing" path. Neglecting the
impact on the database, and the fact that generally the identity of
something doesn't change once it's created...
I have two entity beans, entity A with PK = 1 and entity B with PK = 2.
If I subsequently change these beans so entity A has PK = 2 and entity B has
PK = 1 then what happens when the client issues a request for the entity
bean with PK = 1.
They'll run findByPrimaryKey(1) and get back PK = 1. The container will
look and see if the bean with PK = 1 is loaded, and voila it is. Which bean
did the container find?
It found bean A. The next step depends on whether the bean was deployed
expecting to be reloaded each transaction or not. If for some reason the
container has been told it doesn't need to reload the bean everytime and
bean A is still around, the container will give the client a reference to
bean A instead of bean B which is the bean with PK = 1.
It's not so much the freedom, it just looks a bit sloppy to me.
Cheers
Jay
-----Original Message-----
From: Tim Endres [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 1:35 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB 1.1 and change of primary key values
And rightly so.
Why should the EJB container restrict me from updating the primary key for
an entity bean's record? I can think of many reasons why the primary key
might be changed, and I can think of many reasons why the primary key should
never be changed. It depends on the context. If you want to be certain that
your primary key can not be updated, then change your setPersonId() method
to throw an exception.
tim.
> Yes, something like
>
> Person entity has primary key PersonPK
> Person entity has personId and name attributes.
> PersonPK has personId attribute.
> PersonPK ejbCreate( String name ) returns a PersonPK with the newly
> generated value of personId for this bean.
>
> There seems to be nothing keeping me from having a method on the Person
> entity
>
> setPersonId() which updates the personId attribute within the Person
> entity. Clearly it cannot update the PersonPK object which the container
> has associated with this entity bean in memory.
>
> In EJB 1.1 there doesn't seem to be anything, not even a mention in the
> spec, that this is undesirable behavior on the part of the bean and also
on
> the part of the bean developer to allow such a thing.
>
> Cheers
>
> -----Original Message-----
> From: Jose Gonzalez Gomez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 04, 2001 4:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB 1.1 and change of primary key values
>
>
> Jay,
>
> Correct me if I'm wrong, but I think you are supposing you have some
> fields in your entity bean that act as primary key, is this right?
>
> regards
> Jose
>
> Jay Walters wrote:
>
> > To keep ejb-interest from becoming a ghost town I'll ask a question with
I
> > am hoping an obvious answer.
> >
> > In looking at the EJB 1.1 spec I don't see anything that keeps me, a
bean
> > writer from changing the primary key fields within my entity bean (BMP
or
> > CMP); there is at least one container that would propagate these changes
> to
> > a CMP entity bean into the database.
> >
> > My question is, since the primary key associated with the bean doesn't
> > change; and in general we shouldn't be changing the identity of a bean
in
> > midstream, shouldn't the container or the CMP persistence manager
complain
> > about this? Or at the least shouldn't there be something in the spec
> about
> > not doing this when writing an entity bean? Otherwise locating the bean
> by
> > primary key will be sort of a hit or miss thing depending on whether
it's
> > been re-loaded since the primary key in the bean is updated.
> >
> > Cheers
> > Jay Walters
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
