Imre,
You said (with my comments):
> -----Original Message-----
> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, August 27, 1999 10:06 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Dependent objects vs. Fine grained objects as entity
> beans?, was RE: design question with entity beans
>
> 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.
>
Of course.
> 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.
>
Monolithic? How about the core principle in oo design of encapsulation?
Having every fine grained domain object in ones design as a full fledged
component allows them to be manipulated through their Home life cycle
interface. This breaks encapsulation since life cycle management of an
"owned" object should be from its owner.
> 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.
>
Agreed. Heuristic: If two or more components both need to reference a
related object as part of their graph, then the child object should be a
full fledged component. I don't think OrderItems meets this criteria.
> 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".
===========================================================================
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".
