I'm not sure I understand completely. Is there a design pattern that I may
refer to in order to read more about this technique?
jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Imre Kifor
> Sent: Saturday, February 27, 1999 12:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Inter-Object Business Rules & EJB Transactions
>
>
> I would choose a very different solution while still sticking to the EJB
> paradigm. In addition to having only individual "person" objects (either
> session or entity beans, it doesn't matter), try modeling collections of
> persons as well. You can easily create generic EJBSets and even EJBTrees
> that you can later subclass to get, for example, the tree of
> subordinates in
> your "People project". As soon as you start modeling sets (or
> aggregates) of
> elements as ejb objects you open up your designs to quite powerful yet
> simple and efficient mechanism. Using sets or trees of people, you can
> update your database with one ejbStore operation while still
> propagating the
> changes to all individual elements in your hierarchy of ejb
> objects. And you
> do all this in the ejb framework, not using *any* proprietary server hooks
> or native stuff.
>
> We have used the techniques like the above successfully with our clients
> where set access and aggregate operations were just as frequent (and
> absolutely required) as individual element access and operations.
>
> <PITCH>
> We will be adding samples using our (quite simple) EJBSet and EJBTree
> bundled beans to address aggregation and set operation requirements in the
> EJB framework.
> </PITCH>
>
> Hope this helps,
>
> Imre Kifor
> Valto Systems
>
> -----Original Message-----
> From: James Cook <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Friday, February 26, 1999 8:46 AM
> Subject: Re: Inter-Object Business Rules & EJB Transactions
>
>
> >Just a general comment about the direct JDBC method here:
> >
> >I agree that if this was about pure performance I would want to
> modify the
> >database directly. The question becomes, why use objects if we intend on
> >modifying the database? (Please don't expound on the other advantages of
> >objects, I am trying to make a point :-)
> >
> >My business objects contain business rules. I cannot simply modify the
> >database when I feel like it, unless the same business rules are
> implemented
> >there. This is what we are trying to get away from. I realize that the
> >example below may seem simple enough to go direct to the db, but I could
> >have complex business rules behind such a simple change. I don't know of
> any
> >way to make these changes without going through the object itself.
> >
> >That stated, please agree or disagree with this. If agree, the previous
> >questions/dilemmas still stand.
> >
> >thanks,
> >jim
> >
> >> -----Original Message-----
> >> From: A mailing list for Enterprise JavaBeans development
> >> [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Frentress
> >> Sent: Thursday, February 25, 1999 7:36 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: Inter-Object Business Rules & EJB Transactions
> >>
> >>
> >> > -----Original Message-----
> >> > From: James Cook [SMTP:[EMAIL PROTECTED]]
> >> > Sent: Wednesday, February 25, 1998 1:31 PM
> >> > To: [EMAIL PROTECTED]
> >> > Subject: Inter-Object Business Rules & EJB Transactions
> >> >
> >> > Imagine an organizational chart for your company comprised of
> >> many People
> >> > EJBs. Some People have descendants that represent their
> >> subordinates, and
> >> > these people have subordinates, etc. I have multiple clients
> >> that can make
> >> > changes to these objects.
> >> >
> >> > Suppose I have a business rule whereby, if a People EJB gets a
> >> bonus, the
> >> > same
> >> > bonus is applied to all of his/her subordinates. (Wish this was real
> >> > life!)
> >> >
> >> > Stage set, here are the questions:
> >> >
> >> > 1) Would this business rule be enforced within a session EJB or
> >> the People
> >> > (entity) EJB?
> >> >
> >> i'd do this with a direct jdbc call. no point in
> touching all the
> >> affected entity beans directly to accomplish this (what if there
> >> are 10,000
> >> subordinates - a single jdbc call will definitely be better).
> your choice
> >> where you attach the method for doing it - ejbean or not.
> >>
> >> > I will assume a session for the next questions...
> >> >
> >> > I can imagine a recursive routine that applies the bonus to the
> >> People EJB
> >> > in
> >> > question, gets a list of children, and calls itself for each child.
> This
> >> > will
> >> > effectively traverse the branches.
> >> >
> >> see above, don't waste time touching all the entity
> beans. do it
> >> directly to the pstore and let the beans sync themselves. note
> that your
> >> container must support this and you must have this support
> turned on (ie
> >> Tengah dbIsShared must be set to true or this won't work).
> >>
> >> > 2) Do the EJB transactions provide me with protection to prevent
> someone
> >> > else
> >> > from modifying the first People EJB while I'm off changing children.
> >> >
> >> if you start a tx and make a mod that record in your
> >> pstore will be
> >> locked (implementation of the lock varies by vendor and even
> >> product version
> >> within vendor).
> >>
> >> > 3) Likewise, must I acquire some kind of lock on my entire set of
> People
> >> > objects prior to making my changes. What if someone deletes a People
> EJB
> >> > after
> >> > I get a list of children?
> >> >
> >> see 1st note about a better method.
> >>
> >> > 4) If one of my child People EJBs cannot have a new bonus
> >> applied (due to
> >> > some
> >> > other business rule) will/can all of the other object
> changes be rolled
> >> > back?
> >> >
> >> yes, your update is atomic (ACID rules will be followed
> >> or you need
> >> to switch containers).
> >>
> >> > 5) One of the major strengths of the EJB framework is the concept of
> >> > transactions. Are there any online resources to learn more
> >> about how these
> >> > work?
> >> >
> >> JDBC spec. TPC specs.
> >>
> >> > Thanks,
> >> > jim
> >> >
> >> >
> >>
> ==========================================================================
> >> > =
> >> > 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".
