Thanks for your input on this issue. It's good to see different opinions or
such issues.
>From an application/bean developers point of view: if you're using CMP it is
a somewhat significant step to make orderItems as an attribute of Order and
use jdbc to populate the attribute on load , and managing it's saving to the
db on store. This breaks the isolation of the database layer from the
business objects layer and also makes us have to write extra code to do work
that we want CMP to do.
I'm still not convinced about it causing serious performance problems.
Further if I understand correctly the performance problem will be even less
with Java2. Is that what you are saying Imre ?
Further I agree that it can create a problem if later the object needs to
modeled is independent objects rather than dependent objects.
Just my two cents worth.
Sachin.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Imre Kifor
> Sent: Friday, August 27, 1999 7: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.
>
> 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".
>
>
===========================================================================
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".
