Chris,
I fully intended to send my posting to the list, I just mistakenly replied
to Rickard instead of Robert who asked the question in the first place.
Anyway, my point is that one should strike the right balance when deciding
on what is dependent data and what is full-fledged entity bean.
I have noticed that lately there have been a lot of postings promoting high
granularity, monolithic beans claiming performance advantages and ignoring
well established object-oriented and systems-level practices. The situation
almost seems like "since there will be only one page read, my application
will run much faster if I set the [virtual memory] page size to 10MB". Which
is very true if you are alone on the machine and all your apps fit in
physical memory. It is hardly scalable though.
On another note, if you look inside an efficient ejb implementation, you
will notice that managing context pools, passivation and activation calls
are negligible compared to the large granularity swapping that needs to take
place with large beans in a highly-loaded system.
Once again, I am not proposing to reduce the granularity of beans across the
board, I am only advocating restraint from the "entity beans must be large
granularity or else..." advice I have been noticing on the list. The right
heuristic, IMO, for determining whether a chunk of data should be modeled as
dependent data or a full-fledged bean is whether it should be shared or not
among other bean instances. After all, the whole point of application
servers is to allow efficient sharing of prepared data among a large number
of clients.
Stay tuned for my rumbling about "2nd generation entity architectures"...
Imre Kifor
Valto Systems
-----Original Message-----
From: Chris Raber <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, August 27, 1999 8:53 AM
Subject: Dependent objects vs. Fine grained objects as entity beans?, was
RE: design question with entity beans
>Imre,
>
>I realize you intended this message to not go to the list, but I am glad
you
>sent it here! I respect your opinion. If you don't mind I'd like to keep
>this debate going for a bit.
>
>I agree that a core consideration is whether OrderEntries ever becomes a
>"dependent object" of some other bean. If it does, then it probably needs
to
>manager its own life cycle, and therefor should be an entity bean in its
own
>right (ownership of life cycle is the principle heuristic here). However if
>the likely hood of the heuristic is very low, I don't think the overhead of
>an entity bean is warranted for such fine grained objects. That overhead
>includes the book keeping the container has to do, passivation and
>activation, management of instance pools... Surely we do not want every
>domain object instance in our application managed in this manner?
>
>Another heuristic is whether "finder" functionality is required around sets
>of the object which span the owning parent. If this is the case, then again
>promotion to entity status is warranted.
>
>At the risk of giving you the podium, I would like to here more about
>"second generation entity architecture" which IYHO mitigates the concern of
>fine grained entities being too heavy weight.
>
>Regards,
>
>-Chris.
>
>> -----Original Message-----
>> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
>> Sent: Friday, August 27, 1999 2:06 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: design question with entity beans
>>
>> 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".
>
>===========================================================================
>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".
