Newbie question about EJB-CMP: is it worth it when using multiplecontainers?

[Andrea Desole]

I'm playing around with container managed persistence, and I noticed
that there is no standard that defines the mapping between beans and
databases. In fact, this is what the EJB specification says:

"The Deployer, using the Container Provider s tools, determines how the
persistent fields and relationships defined by the abstract persistence
schema are mapped to a database or other persistent store, and generates
the necessary additional classes and interfaces that enable the
container to manage the persistent fields and relationships of the
entity bean instances at runtime."

If it's true then I will have problems if I have an application that
supports multiple EJB containers, which is my case. So, my question is:
isn't it better to write just some normal SQL once and use bean managed
persistence, instead of writing and maintaining n different files (one
for each container) for the same mapping? How complex should my SQL be
to make CMP really valuable in this case?
Thanks

Andrea

 

[Eugene Ostroukhov]

If you really need EJBs use BMP + some OR mapping like hibernate for
persistance code. But than again - are you sure you need those EJBs anyway?

 

[Andrea Desole]

Actually, hibernate is not a bad idea. I was not thinking about using it
with EJBs. I'll look at it.
I haven't been working for a long time on this application, but I think
yes, EJBs are needed, since there are more applications talking to each
other, sometimes on different machines. Having to use a communication
framework in a Java environment I don't think EJBs are a bad choice.
Thanks for the tip


Andrea

 

[Chris Smith]

I'm playing around with container managed persistence, and I noticed
that there is no standard that defines the mapping between beans and
databases. In fact, this is what the EJB specification says:
[...]

If it's true then I will have problems if I have an application that
supports multiple EJB containers, which is my case.

You should be aware that the EHB specification was not written to allow
randomly swapping the EJB container. The claim is that it was, but the
reality is that various companies have a financial interest in
encouraging you to buy into their platform as opposed to another, so a
lot of the EJB spec is left up to the implementation or limited to the
point that you're sometimes forced to rely on vendor extensions. EJB is
a lot like SQL in this respect; it's possible to write portable code,
but only if you don't have particularly advanced needs.

So if you need to depend on the database schema from outside basic use
of your CMP EJBs, then you've run into such a limitation. You can use
BMP EJBs, perhaps with Hibernate as someone else suggested, or you can
research each of your possible containers and determine how they do the
persistence mapping, and then try to adapt all of them to one schema.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrea Desole]

You should be aware that the EHB specification was not written to allow
randomly swapping the EJB container. The claim is that it was, but the
reality is that various companies have a financial interest in
encouraging you to buy into their platform as opposed to another, so a
lot of the EJB spec is left up to the implementation or limited to the
point that you're sometimes forced to rely on vendor extensions. EJB is
a lot like SQL in this respect; it's possible to write portable code,
but only if you don't have particularly advanced needs.

mmmmm, this is not really the concept of "write once run anywhere" I had
in mind

So if you need to depend on the database schema from outside basic use
of your CMP EJBs, then you've run into such a limitation. You can use
BMP EJBs, perhaps with Hibernate as someone else suggested, or you can
research each of your possible containers and determine how they do the
persistence mapping, and then try to adapt all of them to one schema.

I have to say that, after a further discussion, I now know that a reason
to use EJBs is also that EJBs allow a better control in the case that an
object changes, because a notification is sent, so that all the other
instances, on other machines (in case, for example, of a cluster) can be
updated. I'm not sure Hibernate can do that, and I'm not sure it's
possible to find a good framework that can (maybe JDO?)
Maybe the best option is really to use plain BMP and SQL.

 

[Sudsy]

Andrea Desole wrote:

If it's true then I will have problems if I have an application that
supports multiple EJB containers, which is my case. So, my question is:
isn't it better to write just some normal SQL once and use bean managed
persistence, instead of writing and maintaining n different files (one
for each container) for the same mapping? How complex should my SQL be
to make CMP really valuable in this case?

CMP EJBs are just another abstraction layer atop proprietary RDBMS
interfaces. You write your queries in EJB QL rather than SQL and the
mapping to the underlying data source is typically performed at
deployment time.
If you're performing complex transactions across multiple data
sources then the J2EE features really come into play. CMR and the
"order by" clause (missing from the first version) handle much of
the complexity you would have to manage explicitly with BMP.
IMHO it depends on the complexity of your app. There are certainly
alternatives; DAOFactory immediately comes to mind. Once you get to
a point where you're explicitly managing transactions and relation-
ships, you might have reached the juncture where CMPs can simplify
your life (not to mention your coding ;-).

 

[Andrea Desole]

Andrea Desole wrote:



CMP EJBs are just another abstraction layer atop proprietary RDBMS
interfaces. You write your queries in EJB QL rather than SQL and the
mapping to the underlying data source is typically performed at
deployment time.

true. It's also true that I can create/update/delete with almost no
effort. But the problem with n different configuration files for n
different containers still persists. And most of the times, when I have
to implement CRUD operations or similar, I can use SQL that very likely
will be understood by most RDBMS.

 

[Andrea Desole]

I have to say that, after a further discussion, I now know that a reason
to use EJBs is also that EJBs allow a better control in the case that an
object changes, because a notification is sent, so that all the other
instances, on other machines (in case, for example, of a cluster) can be
updated. I'm not sure Hibernate can do that, and I'm not sure it's
possible to find a good framework that can (maybe JDO?)

never mind, I think I got the point.
The idea is to use Hibernate as a lower layer for the EJBs, so the EJBs
can be regularly used.
Thanks

Andrea