Imre is right. You shouldn't ALWAYS wrap entities with sessions. You
should only do it when you need extra value that a wrapper provides, such as
bulk operations, and transactions spanning entities.
An example of when you'd want to call entity beans directly: You're doing an
E-Commerce deployment where servlets and enterprise beans are running in the
same application server. You hate writing JDBC code from your servlets, so
instead, you write some quick CMP entity beans, and your app server manages
your data access implicitly. Much more RAD than writing JDBC yourself, and
much less buggy.
But as soon as your deployment gets a little more complex (you start doing
multiple tiers and network performance degrades due to all those get/set
calls on entity beans, or you perform transactions spanning multiple entity
beans and you don't want to write to a transaction API) you're going to need
to change all your entity bean client code to use session beans instead.
Yuck.
-Ed
>From: Imre Kifor <[EMAIL PROTECTED]>
>I certainly hope, based on the above, that some posters of this list
>are not simply glorifying a platform shortcoming (i.e. not being
>able to release entity objects thus forcing the use of session
>objects) into full fledged paradigms of EJB usage.
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.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".
