>Ian McCallion wrote:
>
>I disagree. You can safely implement OrderItem as part of Order without
>inhibiting your ability to implement other derived aggregates because you
>can implement other parts of the behaviour of OrderItem in other EJBs.
>Using Imre's example of the BackOrdered entity bean, when a product comes
>off back-order, the behaviour of OrderItem implemented inside BackOrder
>would indicate which orders could now be released for priority fulfilment.
In my posting, I did not even mention sharing of behavior. That is a
non-issue. My concern is sharing of object instances and loaded data.
>I disagree. Larger beans don't create a performance problem per se.
>Swappping can be avoided by ensuring that the system does not try to do too
>many things at the same time, i.e. prioritising work on the basis of "I've
>started so I'll finish" and deferring the starting of transactions when
>necessary. If the logical operation needs a large amount of data then it is
>better to load it and access it efficiently to reduce the time the data is
>resident. This would suggest that you minimise the number of trips to the
>database, get all the data needed initially and don't have fine-grained
>entity beans since the performance of calling an entity bean is much worse
>that that of calling a java class.
I agree if you don't have to share resources and your bean is the only one
in the system. Otherwise, see my previous posting.
>I disagree. First, within a single transaction there will be no
>deserialising/serialising with every call so the difference for this case
>will be the relative performance of calls to java classes and calls to
>EJBs. Second, between transactions (i.e. during user think time)
>serialising/deserialising is a good idea to relieve memory use and is a
>quite tolerable pathlength hit with any half-way decent persistence
>mechanism. Finally, as it is highly unlikely in practice that there will be
>any 'sharing the same "dependent data" instance' this will not make you
>'better off'.
As soon as we bring in transactions into the picture, you have to ask
yourself why db vendors are scrambling so hard to implement row-level
locking in addition to table-level locks. Your answer will be a perfect
answer to why avoiding monolithic beans is, after all, not such a bad idea.
>To sum up, although some may wish it different, about the only way to way
>to ensure good, reliable, predictable, scaleable, portable performance is
>as follows:
That is exactly why I posted my posting. In my experience, your advice about
making entity beans monolithic is too easy to remember (while forgetting
good design practices) and can lead to hard to manage code and not so
scalable end results.
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".
