> > 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. > 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. > > 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. Bear in mind that CD artists don't release CDs all that often. You could still enable caching and either: A) Set a conservative timeout on cached instances (say, an hour). B) Have some manual cache-flush facility somewhere. It doesn't sound good, but works like a charm, performance-wise. My 2c, JP =========================================================================== 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".
