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".
