Thanks for responding Winston. I think the local interface addition in the
current draft handles the networking issues. The remaining bottleneck is the
database access. Repetitive db calls via ejbLoad and ejbStore are a big hit.
BEA has tried to address this with some of their own extensions such as
specifying the database as exclusive so that it is assumed no other SQL
aside from the container will hit the CMP tables. But this is not usually
useful since most environments will have several applications accessing the
db. What I was suggesting was taking this to a smaller granularity and
allowing an individual CMP DD to specify that the table for the CMP was
exclusive (not the entire database). This might allow some functional
partitioning at the db level so that applications can coexist.
Another idea might be when I deploy a CMP, the db could cache a configurable
percentage of rows in-memory (like in the db_block_buffers in Oracle) along
with caching the execution plan for the SQL statement (e.g. in Oracle's
shared_pool). Since I already have the connection in the pool, the access of
a row could be expedited. Implementing this sort of thing would probably
require a DB vendor such as Oracle, Sybase or IBM.
Maybe these suggestions are not reasonable but hopefully there will be some
solution(s) as to how to handle these issues so that users can benefit from
EJB technology without being overconcerned about performance.
>From: Winston Gnananayagam <[EMAIL PROTECTED]>
>Reply-To: Winston Gnananayagam <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Are Entity Beans(CMP/BMP) really necessary???
>Date: Mon, 25 Jun 2001 10:36:43 -0400
>
>Hi John,
> Neither, do I want this technology to die over performance
>issues. But, this definitely is a problem. I believe, the problem stems
>from
>the basic nature of how an Entity Bean interface was defined and how they
>would be accessed & updated. The inherent problem of developing a
>distributed application is the constant need to talk between components
>over
>the network layer with a proprietary protocol. This could become a serious
>bottle neck, if the application starts to have a lot of distributed
>components. I'm hoping that Sun would probably come with a new kind of an
>EJB with an interface that would help access data at a bulk and update them
>in a bulk. That would avoid the network chattiness between distributed
>components. The new interface could probably be modeled like the DAO
>components. If the "stale data" issue is also addressed in the design
>itself, I guess we would have a winner.
> Lets hope Sun does something about it soon.
>Winston.
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.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".
