>
> 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.
>
With the right people you can get time to market with scalability, but it
is naive to think that scalability comes without some rubber meeting the
road. For example, I don't think a platform where a database is
constrained by 32bit addressing is scalable. In other words, leveraging
8GB, 16GB, etc. memory spaces requires some work in coupling to a specific
database platform (i.e., leverage platform features).
> 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.
>
I see CMP today valuable in rapid prototyping. I don't think you want your
normalized schema coming from data modeling (data view), but rather I think
an initial normalized schema falls out of a good object model (behavioral
view).
Leverage things like SPROCs to hide RDBMS details from entities. If a DBA
decides to toss a view in or update two tables for a single entity
creation...so be it, try and reduce the impact of these changes in the
entity beans.
> 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.
>
I would argue that a tool can't magically solve the scaling issues of
dealing with database technology. So pure automated mapping is a concern in
larger systems (unless there is a well defined and easy way for DBA types to
circumvent the tool without impacting the software).
> 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).
>
I guess, I don't see CMP being "smart" enough. Having lived the large scale
production world with oracle, Sybase, etc....I know it requires in depth
"human" experts to constantly troubleshoot, tune and optimize a large scale
DBMS.
-phil ([EMAIL PROTECTED])
Phillip A. Lindsay
eBuilt, Inc. - http://www.ebuilt.com
> 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".
