Hi Ken,
Hope, I'm not being a pain. But, I guess asking some hard
questions would not only help me, but also help others to move in the right
direction.
<Ken>
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.
</Ken>
Can you explain about this transaction overhead a little more in
detail or could you point me to a discussion regarding this. Under what
conditions does this overhead becomes a major performance kill??? In my
understanding ,I thought every Entity bean always runs within its own
container managed transaction demarcation. So, what difference would it
make, if the Transaction was initiated from the session bean or the
entity-bean???
<Ken>
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.
</Ken>
I dont see a major difference while accessing frequently used rows
between, making a remote call to an entity bean for getting data vs calling
the database directly. In both cases, u are making a remote call and the
data is being kept in memory(all modern relational databases caches data in
memory).
Also, while updating records, based on my design, I make SQL calls
using JDBC. But, isnt that same SQL also used underneath by the CMP bean to
update the database and keep itself synchronized. A CMP bean only makes
those SQL statements transparant to the developer. So I guess, I'm not
incurring any added overhead by making JDBC calls directly. On the other
hand, keeping the CMP bean synchronized with the database, in a multi-user
environment is itself a major over-head.
Some arguments where also made(at work), that when using Session
beans to access data, you might end up with "stale data". So, I'll have to
address those issues, while basing my design around session beans. But, I
guess you would encounter with the same "stale data" issues when using
Entity Beans and have a Value Object on top of it too. The design patterns
suggests, using the Value objects for bulk retrieval and to also update the
data as a bulk(to avoid remote chattiness between beans). This way, the VOs
can anytime become "stale", after a client gets a copy of the VO. You will
have to address this issue invariably.
Steve,
I definetly agree with you that DAO's play a significant role in
filling gaps in the J2EE architecture. I hope the EJB Spec itself would
evolve to accomodate the DAO's in the future.
I didnt have a chance to take a look at the "Business Components for
Java Framework" from Oracle. I'll surely look into it. But, I'm hoping, its
not tied down to only the Oracle Application Server.
Thanks
Winston.
===========================================================================
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".
