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.
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.
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.
Moreover, for very good reasons, the spec does not allow passing regular
Java objects (i.e. dependent data) by reference among local beans. If you
consider the overhead of serializing/deserializing dependent data with every
call, you most probably will be better of making the call to the (local)
bean instead and sharing the same "dependent data" instance.
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 :-)
Imre Kifor
Valto Systems
-----Original Message-----
From: Rickard �berg <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, August 27, 1999 12:57 AM
Subject: Re: design question with entity beans
>Hey
>
>Robert Krueger wrote:
>> suppose I have to model an entity (say Order), that aggregates a vector
>> of other entities (say instances of OrderEntry) and I would like to
>> avoid the performance problem of reloading/storing all the aggregated
>> entities (because there possibly is a large number of them) on each
>> access to methods of entity bean class Order. would it be ok to put
>> methods that access the db directly (like addOrderEntry,
>> getOrderEntries) into the entity bean Order and not model OrderEntry as
>> an entity bean? does this violate the spec or is it bad design and there
>> are much better patterns for modeling the problem without performance
>> problems? are there data integrity problems with this approach?
>
>What Chris and Vlada talked about are possible solutions.
>
>An Other Solution is to make the OrderEntry an EntityBean and include
>the following method in Order:
>public Enumeration getEntries()
>{
> // Find from OrderEntry home!
> return oeHome.findByOrder(this.id);
>}
>
>I.e. do it "lazily", but keep the interface simple.
>
>/Rickard
>
>--
>Rickard �berg
>
>@home: +46 13 177937
>Email: [EMAIL PROTECTED]
>Homepage: http://www-und.ida.liu.se/~ricob684
>
>===========================================================================
>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".
>
>
===========================================================================
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".
