I totally support you on the notion that DBA role is very significant as
far as performance, transactional integrity, concurrency and all other
considerations play part. I would always recommend BMP in front of CMP,
I would rather write mode code but get a better application. But for
many people time-to-market and portability of code is more important,
where CMP works better.
Tell me what you think of the following two options.
1. You build a CMP bean based on the RDBMS schema specified by the DBA.
Your bean is tuned to the database server you use and the CMP engine
gives you certain guarantees (well documented) just like JDBC does
today. For everything that does not work transparently, you mix CMP with
BMP.
2. You buy or get a CMP bean from a third party. You use mapping that
conform the bean to the RDBMS requirements. For example, your object
might be using an Integer or a String, but the RDBMS is tuned to use
TINYINT or CHAR(30). The CMP takes care of the proper translation. You
can use any arbitrary mapping based on what works best for your RDBMS.
If the CMP engine has enough room to give you that sort of flexibility
than for some applications it would be even better than BMP. Tuning a
BMP engine for Oracle, Sybase, DB2 is not trivial. But relying on a CMP
engine that has the proper mechanisms might get you better results in
many cases (never all cases).
arkin
Phillip Lindsay wrote:
>
> IMHO, I don't see a robust large scale system deployed with CMP (yet). The
> idea that any large system is deployed without a significant DBA role is
> scary. No matter how much testing and design, in any heavily utilized
> RDBMS based production system there will always be a need for RDBMS schema
> tweaks out of band of the software components.
> To get better transaction performance you will be forced into BMP.
>
> -phil ([EMAIL PROTECTED])
> Phillip A. Lindsay
> eBuilt, Inc - http://www.ebuilt.com
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 21, 2000 12:01 AM
> > To: Recipients of EJB-INTEREST digests
> > Subject: EJB-INTEREST Digest - 19 Jan 2000 to 20 Jan 2000 (#2000-20)
> >
> > The model I described is the one you should be pursuing. And a good CMP
> > engine should allow you to persist a graph of objects. Sadly, not all
> > EJB servers can do that. It's a shame considering such solutions have
> > existed in the industry for years.
> >
> > If your EJB server is one of the many that only persist one object to
> > one table, then you have to go around by either making all the objects
> > entity beans, or implementing ejbLoad/ejbStore in Order to deal with
> > PurchaseOrder. But in that case, you might as well do everything BMP and
> > save some performance.
> >
> > The spirit of the EJB specs is very clear, it's just that not all EJB
> > servers fulfill the true needs that are not explicitly expressed in the
> > specs.
> >
> > arkin
> >
> >
> > Nathan Phelps wrote:
> > >
> > > I understand what you are getting at here, however my main
> > concern is that
> > > since a Purchase Order most likely represents data, it is going
> > to have to
> > > know how to talk to the storage mechanism. In other words, all the
> > > wonderful services EJB offers (like CMP) don't directly apply to the
> > > PurchaseOrder class because it doesn't implement the EntityBean
> > interface.
> > > I will either have to code JDBC in the PurchaseOrder class or
> > create data
> > > objects for the class to use. This will definitely effect the
> > portability
> > > of the object in my mind. So how can I implement these "helper" classes
> > > without violating portability?
> > >
> > > Thanks,
> > >
> > > Nathan Phelps
> > > solarc.com
> > >
> > > > -----Original Message-----
> > > > From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, January 18, 2000 9:48 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Fine-grained data in container managed entity beans
> > > >
> > > > public class Order
> > > > implements EntityBean
> > > > {
> > > > PurchaseOrder pOrder;
> > > > Vector lines;
> > > >
> > > > . . .
> > > > }
> > > >
> > > >
> > > > public class PurchaseOrder
> > > > {
> > > > }
> > > >
> > > >
> > > > public class OrderLine
> > > > {
> > > > }
> > > >
> > > > arkin
> > >
> > >
> > ==================================================================
> > =========
> > > 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".
> >
> > --
> > ----------------------------------------------------------------------
> > Assaf Arkin www.exoffice.com
> > CTO, Exoffice Technologies, Inc. www.exolab.org
> >
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
