Hi Se Hee,
The finder mechanism is quite different across appservers in terms of ease
of use and functionality. I believe EJB 2.0 will address this in some way.
Does anybody know how to obtain early drafts? When?
William Louth
> -----Original Message-----
> From: Se Hee Lee [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 02, 2000 2:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CMP vs. BMP (3rd try)
>
> How hard is it to deploy the CMP EJB in multiple application servers? What
> I
> am saying is, is it relatively painful to move from Weblogic or Gemstone,
> and vice versa with all the finder methods, etc? If this is not true, then
> I
> think it's more coding for BMP, but it's less headache for deployment
> which
> in turn pushes the development in that direction...
>
> Se Hee
>
> -->-----Original Message-----
> -->From: A mailing list for Enterprise JavaBeans development
> -->[mailto:[EMAIL PROTECTED]]On Behalf Of Karl Avedal
> -->Sent: Tuesday, May 02, 2000 5:01 AM
> -->To: [EMAIL PROTECTED]
> -->Subject: Re: CMP vs. BMP (3rd try)
> -->
> -->
> -->Hello Ingo,
> -->
> -->I'd like to even further summarize your comparison, since I
> -->think you do mention a
> -->few issues that should fall under the same category.
> -->
> -->Why use CMP?
> -->
> -->* Simplicity
> -->* Performance
> -->* Database portability
> -->
> -->Why use BMP?
> -->
> -->* Full control
> -->
> -->My conclusion is that BMP should only be used when you
> -->really do need full control,
> -->for any of the reasons you mention. Otherwise, use CMP.
> -->
> -->>
> -->> I have summerized the pros and cons regarding CMP and BMP
> -->from posings on
> -->> this list. Please send your comments, tell me if you have
> -->a different
> -->> opinion in certain points or if I missed something important.
> -->>
> -->> Pro BMP:
> -->> * Ability to express complex relationships among data.
> -->
> -->> Contra CMP:
> -->
> -->> * Difficult to use with complex database schema.
> -->
> -->I have to comment on this issue since I think it's often
> -->described as a bigger deal
> -->than it really is. I agree that CMP might not give you the
> -->control you need at all
> -->times, but in a decent container you can express pretty
> -->complex relationships.
> -->
> --><vendor>
> -->In the Orion Application Server you can have many kind of
> -->relationships between
> -->entities. You can (of course) keep entity bean references
> -->directly in another
> -->entity bean, but you can also keep a Collection of entity
> -->beans (or a List, a Map
> -->or a Set). This does provide pretty strong support for
> -->complex relationships. Of
> -->course, until this is standardized it will be dangerous to
> -->use, but this is a
> -->temporary problem.
> --></vendor>
> -->
> -->>
> -->> 1. Does a container, as a matter of principle, have more
> -->facilities to
> -->> optimize the persistence (e.g. only the container has
> -->knowledge which
> -->> other transactions are currently running -> run-time
> -->optimizations). If
> -->> yes, the consequence would be that sooner or later CMP
> -->_will_ be the
> -->> alternative with the best performance?
> -->>
> -->
> -->Yes, the more abstract the description is, the more the
> -->Container can step in and
> -->optimize things.
> -->
> -->This is of fundamental importance and is why HotSpot can
> -->perform so well and why
> -->it's hard to write assembler-code that is faster than the
> -->code generated by an
> -->optimizing C compiler. It's easier to optimize higher-level
> -->descriptions.
> -->
> -->>
> -->> 2. Are containers really not mature yet (in a sense that
> -->BMP is still much
> -->> faster than CMP)?
> -->>
> -->
> --><vendor>
> -->I can only speak for Orion, but in our tests, CMP is
> -->normally much faster than BMP
> -->today. I'm sure this is the case with some other servers
> -->too, and will be the case
> -->for all once they employ all possible optimizations.
> --></vendor>
> -->
> -->Regards,
> -->Karl Avedal
> -->The Orion team (http://www.orionserver.com)
> -->
> -->=============================================================
> -->==============
> -->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".
> -->
> -->
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
