Hi,
thanks for the effort with answering my questions! To maybe better explain
what I'm aiming at here:
- Using CMP and CMR I can have a nice EJB scenario with 1:n relationship
Artist <1:n> Cd. My understanding is that container is responsible
for handling the relationship code so that I can always trust that
I'm getting valid references no matter how I use cd.getArtist(),
cd.setArtist(), artist.getCds(), artist.getCds(). When implementing
the beans, I do not have to worry about whether there is caching or not,
what is the caching strategy, etc. That I can leave to container,
which is the added value of EJB's.
- I believe same thing _should_ be reachable using BMP's. I should be able
to create BMP entity beans that keep the references valid with
any use of cd.getArtist(), artist.setCds() etc. I should not have to worry
about caching, trascations etc. as long as I follow the rules regarding
call-back methods ejbLoad(), ejbActivate() etc - that's what the container
is there for! But how to do this?
- 1:n relationships are quite common in all designs so this should be a
common and basic problem.
- If using remote interfaces is a problem, I think having only local
interfaces to entity beans is perfectly acceptable.
>> >> 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).
>
>Super. EJB instances are cached.
>What's the caching schema?
Do I have to know that? Can't I leave it to container / decide it
deploy -time?
>Relationships are lazy-loaded. How?
>You load the PK's for the relationships lazily?
>You have a special Collection implementation that loads the EJBs lazily?
>Both?
Like:
ArtistBean {
private Collection cds;
private boolean cdsLoaded = false;
public Collection getCds() {
if (!cdsLoaded) {
try {
BmpCdLocalHome cdHome = (BmpCdLocalHome) HomeFactory.getInstance()
.intraEjbLookUpEjbRef("java:comp/env/ejb/Cd");
cds = cdHome.findByArtistId(id);
cdsLoaded = true;
} catch (NamingException n) {
throw new EJBException (n);
} catch (FinderException f) {
throw new EJBException(f);
}
}
return cds;
}
/*...ejbLoad() / ejbStore() do not touch cds. So far I have artist.cds as
read - only.*/
}
Cd {
private Integer artistId;
private BmpArtistLocal artist;
private boolean artistLoaded = false;
public BmpArtistLocal getArtist() {
if (!artistLoaded) {
try {
BmpArtistLocalHome artistHome = (BmpArtistLocalHome) HomeFactory.
getInstance()
.intraEjbLookUpEjbRef("java:comp/env/ejb/Artist");
artist = artistHome.findByPrimaryKey(artistId);
artistLoaded = true;
} catch (FinderException f) {
throw new EJBException(f);
} catch (NamingException n) {
throw new EJBException(n);
}
}
return artist;
}
public void setArtist(OBmpArtistLocal artist) {
this.artist = artist;
this.artistId = artist.getId();
this.artistLoaded = true;
}
}
>> // make sure that artist EJBs reference the right cd EJB
>> artist.addCd(this);
>
>What's that? You can't pass 'this' there. Pass the PK or the handle.
Ok, sorry, that was just pseudocode, that would be handle then....
>Bear in mind that if you execute this code:
>
>Artist {
> addCd(Cd cd) {
> cdList.add(cd.getPrimaryKey() );
> }
>}
>
>You'll need to mark the bean as reentrant.
Why? Client -> Artist.addCd() -> cd.getPrimaryKey() - there's no loop or
re-entrancy? Of course if you mean that artist.addCd() was called from
cd.setArtist - yes, there's a problem. And marking the bean as re-entrant
opens up another can of worms, I think. Oh well...
>> 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.
>
>I also take it that you're planning to use Remote interfaces. That's the
>whole problem. With local interfaces the container can make certain
>assumptions that will allow for complete consistency without huge
>performance penalties.
>
>Essentially it boils down to these situations that the container must
>handle somehow:
>
>You're using Remote interfaces (so calls and lookups may come from
>anywhere).
>
>When do you issue the ejbStore call? Right away, at certain intervals,
>at the end of the transaction?
>If you fire it before the transaction commits, how does your database
>rollback segment behave?
>If caching is enabled, when will cached instances on other servers be
>updated?
For sure container should call ejbStore before the end of transaction,
I would imagine. You cannot call it after the trasaction has ended. How
could commit / rollback work then? Sorry, maybe I
missed your point...
I'm quite happy with having only local interfaces to the entity beans since
they are usually behind session facade anyway. There has to be way to
implement relationships with BMP's decently, a la CMP CMR. After all a
well-known design strategy is to implement BMP that inherits CMP, so that
you can deploy CMP's when you container supports them, or fall back to
BMP's with more limited containers.
http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/
Those who implement this strategy and use CMR with CMP's have to solve this
problem with BMP's...
Can anybody point to a good source of information on how to handle entity
bean relationships correctly with BMPs?
===========================================================================
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".
