Sachin,
> -----Original Message-----
> From: Sachin Aggarwal [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, August 27, 1999 8:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Dependent objects vs. Fine grained objects as entity
> beans?, was RE: design question with entity beans
>
> I don't want to store OrderItems as a seriazed String attribute in the
> database. In business applications there are often some reports that run
> directly against the database and they need to be able to access the order
> items and their attributes.
>
I was certainly not suggesting that approach.
> In this scenario which should be pretty common I didn't think I could go
> to
> my deployment descriptor for the OrderBean and map a Vector instance
> variable to a seperate relational table and provide the "join field" to
> connect the orderItems with the order.
>
Exactly. And your OR mapping layer should allow for the child object to be a
bean or non-bean object.
> Am I missing something ?
>
Nope.
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > Sent: Friday, August 27, 1999 3:31 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Dependent objects vs. Fine grained objects as entity
> > beans?, was RE: design question with entity beans
> >
> >
> > 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".
> >
> >
>
> ==========================================================================
> =
> 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".
