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".
