>Very interesting this Ejipt implementation. Will you describe how this is
>accomplished? To continue the example that started this thread, when
>applyBonus() is called on an EJBSet, how is it that all the members of the
>set can have their state altered (eg have applyBonus() invoked) but not
>issue JDBC calls? I can imagine possibilities but I'd like to know how
Ejipt
>handles it.
I will be happy to give you the details off line on how we are implementing
situations similar to the above with the minimum number of database calls
strictly using the EJB paradigm. As a matter of fact, we have working code
that does multiple, more complex aggregations than the above with only 2
fully transacted JDBC calls on 1000 member sets (actually the cardinality of
the sets is not important for the number of JDBC calls).
> Must the call be via stored procedure?
<PITCH>
With the current Ejipt CMP, stored procedures are required. Ejipt 1.1 (due
out by the end of March) will lift this requirement. At that time you will
be able to use a simple SQL UPDATE statement instead.
</PITCH>
>As a complicator, what it the stored procedure above has side-effects on
>other parts of EJB's in your transaction, will the values appear in the
>beans? When do the values appear (if they do), at the end of the
transaction
>or as the values are generated by the stored procedure?
This really boils down to the question: "do your beans have total control
over your database or not?". If the stored procedure has side effects, then
the affected beans would have to be reloaded before a subsequent method call
comes through. This is a standard EJB requirement anyway. I can explain off
line how you can use caching in Ejipt to still minimize the database calls.
>BTW: what does the word "Ejipt" stand for?
Enterprise Java ImPlemenTation :-)
>Also, is it correct to say that
>Ejipt is targeted to embedded systems or is it reasonable for use as a
>general EJB server?
<PITCH>
You can use Ejipt in either standalone or embedded mode. It is less than
300Kb. With the next update (1.0.3 due out late next week), we are including
samples for 1) using Ejipt as an instance directly in your Java code, 2)
subclassing and using your custom Ejipt in your code, 3) using it as a
standalone server (without remote activation) and 4) using it in failsafe
mode (with remote activation). It will be up to you how you want to use it.
</PITCH>
Imre Kifor
Valto Systems
>> -----Original Message-----
>> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
>> Sent: Saturday, February 27, 1999 1:30 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Inter-Object Business Rules & EJB Transactions
>>
>>
>> Excellent description and accurate pitfall analysis of both techniques!
>>
>> To increase performance, we usually optimize performance sensitive
>> ejbStores
>> (where a simple iteration would be prohibitive) of our EJBSet derivatives
>> (e.g. People object) by using specialized stored procedures on the
>> database
>> side. That way only one JDBC call will do the trick. <PITCH>Ejipt CMP
>> allows
>> the developer to specify the exact SQL statement or stored procedure to
be
>> used while persisting.</PITCH>
>>
>> "As always, use the proper tool in the context of your requirements". I
>> could not agree with you more.
>>
>> -----Original Message-----
>> From: Jim Frentress <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Saturday, February 27, 1999 3:39 PM
>> Subject: Re: Inter-Object Business Rules & EJB Transactions
>>
>>
>> >Both designs have their merits, and both can be successfully employed.
>> >
>> >Imre refers to EJBSets (and Trees). To address EJBSets, they extend an
>> >EJBObject and (probably) delegate to a JDK2 collection. They allow
>> >collections of objects to be treated exactly as an individual EJBObject
>> is
>> >handled (Composite). Imre is correct, there is power here. However, to
>> say
>> >you can "update your database with one ejbStore operation" is a tad
>> >misleading. Don't get me wrong, what Imre says is 100% correct but it's
>> >misleading because someone might infer that this results in just one
JDBC
>> >(assuming RDBMS) call for a set of EJBObjects. EJBSet will iterate
>> members,
>> >applying changes in the process. Each EJBObject is going to issue a
>> pstore
>> >change.
>> >
>> >My design has merit but contains pitfalls too. The basic issue is that
>> you
>> >can change the pstore under the EJBServer without the server being aware
>> of
>> >it. Any data you change that is represented by an EJB currently in a
>> >transaction runs some risk. My feeling is that a good EJBServer should
>> >mitigate this risk. You've got to be careful about including EJB's in
>> your
>> >transaction that could have their data changed by your call too - for
the
>> >same reasons.
>> >
>> >As always, use the proper tool in the context of your requirements.
>> >
>> >> -----Original Message-----
>> >> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
>> >> Sent: Saturday, February 27, 1999 9:27 AM
>> >> 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".
>> >
>>
>>
==========================================================================
>> =
>> 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".
