Hi,
OK, my example was a bit simplistic. Artist and Cd were picked just as
examples, this is not a real case, you can think of it as any ordinary 1:n
relationship.
>> Now, I would implement this so that the relationship fields
>> (Cd.artist and
>> Artist.cds) are lazy loaded.
>
>This implies that you're not caching anything. Transaction isolation
>comes into play here as well. These are important details when
>considering stale-data scenarios.
In this example I'm assuming that there is caching of EJBs which is handled
by container. And that the transaction is initiated by a call to session
bean (session facade).
>> Calling set() -methods would
>> update both the object and the parameter object, ie.
>> bornInTheUsa.setArtist
>> (bruceSpringsteen) would update both bornInTheUsa.artist
>> field AND bruceSpringsteen.cds collection (otherwise
>> bruceSpringsteen will have invalid state after the call).
>
>Not necessarily. It would have an invalid state after the
>transaction finishes, if it's not voted that it should rollback. I
>mention this so that you're aware that in other methods within the
>same TX the inserted relationship *may* not show.
>Again, TX isolation comes into play as well.
I'm sorry, I did not quite get that. Do you mean that, if I create cd.
setArtist() method like:
Cd {
setArtist(Artist artist) {
Artist previousArtist = this.artist;
this.artist = artist;
this.artistLoaded = true;
// make sure that artist EJBs reference the right cd EJB
artist.addCd(this);
if (previousArtist != null) {
// the old artist no longer has this cd
previousArtist.removeCd(this);
}
}
}
And call it from session bean like:
// user changed some record's artist
Artist newArtist = artist.findByPrimaryKey(newArtistIdFromUser);
Cd editedCd = cd.findByPrimaryKey(cdIdFromUser);
editedCd.setArtist(newArtist);
either editedCd or newArtist could have invalid state after setArtist(); ?
What I am trying to accomplish here is nice automatic relationship handling
a la CMP CMR but with BMP. I am aware that it is probably not the easiest
route, but this is for testing / education purposes.
>> Is this the right way to go? Plus, can I trust that in
>> clustered environment also EJB's in other instances are
>> updated?
>> So that there is not an invalid artist bean in some
>> instance having bruceSpringsteen.cds missing the bornInTheUsa?
>
>As long as you don't cache the entities(and make sure the container
>doesn't do it for you either), yes you can trust.
>As a sidenote, I'd monitor performance if there's no caching at all.
So, with caching, I cannot trust that the relationships of all instances are
valid?
===========================================================================
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".
