Ian McCallion wrote:
>I assume a horizontal scaleability design point involving multiple copies
>of the EJB server, on multiple JVMs, on multiple machines each accessing
>the same database that is also shared with other (EJB or non-EJB)
>applications. With a horizontal scaleability design point, the usefulness
>of caching bean instances is limited and EJB servers supporting this design
>point must aim to give acceptable performance without caching.
>[...]
>Well horizontal scaleability says that the database, not an object cache in
a
>JVM, is the point of data (re)use and sharing. Hence efficient access to
>the database (rather than use of a hashtable) is key to performance. This
>appears to me (sorry if I'm wrong) to take away Imre's main argument for
>fine-grained EBs, because having multiple EBs access the database
>separately could not be more efficient than a coarse-grained EB making a
>single request. Thus there are no gains which can compensate for the
>overhead of extra EB->EB calls inherent in fine-grained EBs, i.e.
>coarse-grained EBs will generally perform better than fine-grained EBs.
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.
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.
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.
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.
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.
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>
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).
Clearly, I am not convinced about the benefits of large-granularity beans. I
still maintain that you should use the *right* size bean that fits your
conceptual model, usage, load and tools. Go figure...
Imre Kifor
Valto Systems
===========================================================================
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".
