Imre Kifor wrote:
> If you ever plan to share OrderEntries among other entities (either
Orders
> or various other derivative aggregates like BackOrdered), you will be
better
> off not modeling OrderEntry as a dependent object. In my experience, it
is
> far more difficult to upgrade a dependent object to bean status than vice
> versa. Keep in mind that according to the spec "[...] the object A fully
> manages the lifecycle of the [dependent] object B." in 9.1.2.
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.
This is an example of the liberating principle that the mapping of OO model
objects to runtime constructs does not need to be 1-1 and in fact can't be
1-1 in any layered deployment architecture because different bits of a
domain object's behaviour will be implemented on different layers.
> Another issue is scalability. Your specific Order may not contain a large
> number of OrderEntries, however, as a more general principle, the larger
the
> granularity of your beans, the less your beans will perform under heavy
> load. Just imagine the swapping your OS would go through if it had 1MB or
> 10MB virtual memory pages and not enough physical memory.
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.
> To be more concrete, the larger your beans are (in number of methods,
number
> of possible clients and size of state) the less advantageous the
separation
> between ejb objects and bean instances is. That is under heavy load, of
> course. If you have the luxury to keep everything swapped in (i.e. in
> activated state), then this is not an issue.
I disagree. Same reasons as above.
> Moreover, for very good reasons, the spec does not allow passing regular
> Java objects (i.e. dependent data) by reference among local beans.
I agree.
> If you
> consider the overhead of serializing/deserializing dependent data with
every
> call, you most probably will be better off making the call to the (local)
> bean instead and sharing the same "dependent data" instance.
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'.
> A good, second generation entity architecture will also help you if you
> decide to lower the granularity of your beans. Of course, with everything
> else in life, balance is the key :-)
No comment.
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:
(1) Make Entity beans coarse-grained:
- Inter-EJB performance is such that you do not
want a high rate of calling within a
transaction.
- EJBs are designed to be a visible unit of
management for performance, security,
availability, change, etc. You do not want to
manage fine-grained beans.
(2) Instantiate during EjbLoad all the data that an
entity bean definitely needs and all the data it is
likely to need during EjbLoad. Lazy load only
the data that it rarely needs.
(3) Keep transactions "short".
- Always commit before returning control to
the user
- Only do the work that is logically necessary
in a single transaction.
(4) Avoid depending on EJB instances being kept
in memory between transactions.
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".
