Sachin,
Making OrderItems a dependent object does not necessarily imply that you
must hand code the JDBC for the dependent object. I am not sure where this
intuition comes from, it must be based on the limitations of certain CMP
implementations.
-Chris.
> -----Original Message-----
> From: Sachin Aggarwal [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, August 27, 1999 2:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Dependent objects vs. Fine grained objects as entity
> beans?, was RE: design question with entity beans
>
> 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".
===========================================================================
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".
