Imre Kifor wrote:
> In my opinion, you are making a strong case *against* using
> large-granularity beans. Here is why:
> 1) since you must synchronize with the database at both the
> beginning and the end of every transaction, at least you
> should minimize the work this entails. That is difficult
> with large beans, unless you transfer large blocks of data
> blindly. Which leads to complicated code, fragile,
> hard-to-maintain datastructures and cumbersome error
> handling on the bean's end.
Yes these complications exist. However I'm more optimistic than you that
tools do/will soon take away the technical challenge of getting the code
right. I believe that is an appropriate direction for tool developer's
creative efforts.
> 2) the larger your beans are, the more "server" logic you
> have to duplicate into them to support selective updates.
> Note: it is very difficult to do en masse storing of state
> with JDBC.
Yes these complications exist. Same comment as above. JDBC may indeed be an
area where improvement is possible.
> 3) the larger your beans are, the more likely they will be
> accessed often and, consequently, locked often and for
> longer periods of time by transactions. This fact
> single-handedly will eliminate the scalability of your
> system.
No. I hope it's clear that even with coarse-grained entity beans there is
no particular reason to assume that the application locks data that does
not need to be locked. Furthermore, doing "unnecessary" locking does not
necessarily cause problems e.g. locking all order items for a particular
order during a transaction to add an order item to the order will not
affect the ability to process multiple orders simultaneously.
> 4) the larger your beans are, the more likely you will lock
> more database objects (tables, rows etc.) during calls.
> Excellent way to reduce the scalability of your database
No. Same comment as above.
> 5) it is said frequently on this list that transactions
> should be short. The shorter your transactions are, the
> faster your claimed benefits of large beans evaporate.
No. My claimed benefits don't relate to performance but to the need for a
coarse-grained component model with capabilities most of which EJB already
has (see the archive). Obviously I do believe that properly designed
coarse-grained components will perform and scale well.
> 6) the larger, more complicated your beans are, the less
> chances you have to find a CMP implementation to support
> your scheme. <vendor>Ejipt CMP will let you do it
> :-)</vendor>
Yes, not all CMP implementations can do it today. But my purpose in
engaging in this discussion is to try to gain consensus on the design point
in order to aid AD tool, application server, system management product and
component vendors to know what to aim for. Lack of consensus fragments the
java solution and opens up the opportunity for the COMpetition (sic) to
present a more complete, coherent and attractive solution.
> 7) and then you should consider the impact of large beans
> on the resources of your EJB server (see my virtual memory
> page size rant in the archives)
No. I countered this by pointing out that an application using
coarse-grained EBs does not necessarily instantiate lots more data than it
needs to. Additionally, short transactions, plus not depending on the data
being cached in the JVM, plus the "I've started so I'll finish" server
scheduling strategy enables an application that does need to instantiate a
lot of data to support concurrency.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
