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".
