>Hi Ken,
> Thanks for the reply. I understand from the message, that your
>approach would be to use session beans to do search queries for accessing
>data, instead of using finder methods. Then load the appropriate CMP bean,
>if necessary to interact/update the data that one or more clients deal with
>to maintain a persistent state. Please let me know, if I interpreted your
>design correctly.
> If, I had interpreted it correctly, I feel that the CMP bean is
>primarily used only for data updation. Where most of the complex data
>retrieval logic is being implemented on the session bean. Wouldn't it be
>more better to implement the data updation logic in a normal java class.
>This way we could avoid all the data marshalling/unmarshalling over- heads
>that's inherent with a CMP bean.
>Thanks,
>Winston.
>
>
FIrst, I think this approach is valid for both BMP and CMP beans. Regarding
the overhead, let me say that if you let every entity bean method run inside its
own transaction, the overhead probably will kill your performance. However, if
your session bean begins a transaction before it calls any entity bean methods,
you cut way down on the overhead. Second, _depending upon your application
requirements, session beans could be more ineffecient for data manipulation. If
I have entity beans modelling a cetain something, say inventory items, and 100
of the rows in my database are accessed frequently, the entity bean instances
will probably stay in active memory, already instantiated and initialized, to be
reused by various session beans. If the session beans do all the data access,
they pay all the JDBC costs every single time they do anything. Every SQL call
from JDBC will start at least a local transaction.
So, in my view, if you use entity beans judiciously, they can be effective
for what they are supposeed to be: object models of persistent data. If you do
all your SQL work in session beans because you believe that it will always be
more effecient, no matter wahat, you may be robbing Peter to pay Paul. That is,
in the believe that entity beans are too ineffecient, you are paying the same
overhead but through different mechanisms.
Then again, depending upon your application, it may be more effecient to not
use EJBs at all. I know that may sound like heresy here, but as I tell
customers all the time, if what you need primarily to do is simply browse, like
the collection at a library, or the items in inventory, and can do little or no
updates, and there is little logic involved, using a web tier component, or RMI
object is probably a lot more effecient. This has lots of caveats, but it is
worth consdiering. SO if you just want to view data in one shot, I probably
wouldn't use an EJB at all, depending again upon application requirements. That
is, I don't think it's possible to say in the abstract "You should always use
EJBs' or that "Entity beans are bad." BOth extremes I think are probably,well,
too extreme.
Ken Litwak
===========================================================================
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".
