----- Original Message -----
> Al:
>
> YES. I'm starting off with the hypothesis that all database tables
> should map to EJBs, because that is what all the hype is about.
>
> Now, for real world, does it work well?
> Al:
>
> YES. I'm starting off with the hypothesis that all database tables
> should map to EJBs, because that is what all the hype is about.
>
> Now, for real world, does it work well?
Yes and no. There is a terribly large
amount of overhead involved in EJB to begin with, then you start adding all the
RMI calls over the network and that adds some load too. In general we try to
model our EJB such that we minimize the Entity beans. Certainly they are handy,
but let us take a classic example of a person bean. A person also has an
address, now addresses dont change much so I really dont see a lot of sense in
deploying an address bean that will sit for most of the time in the pool and not
be instantiated. So I would just use a regular class (which may get a datasource
from the JNDI services) and do this address class using regular JDBC. So yes
entity beans work well, but we as a java community have "fooled" ourselves into
thinking that if it is a table in a database it should be an entity bean.
>
> Is you answer that one should make create an EJB that
> is not CMP, but rather one supplies a hand crafter SQL
> command somewhere in its member functions?
>
> Is you answer that one should make create an EJB that
> is not CMP, but rather one supplies a hand crafter SQL
> command somewhere in its member functions?
>
Yes, you can use bean managed
persistence to handle this. In your case it should be rather simple since you
seem to have a built in primary key (D) so it would work easy. There are some
situations, especially when doing the kinds of things you are talking about
where BMP is the only way to go. Because of complex joins or the need for a
complex primary key. it does put more work on the bean developer but in some
cases it may be the only way to go.
Al
