Robert,
You are not alone in your problem :(
The problem that you are experiencing stems from the need to retrieve
instance data (state) for each entity bean during an update. As you've
noted, the programmer must weigh the performance penalty for doing so, with
the business rule isolation that is lost.
This is very similar to any of the findByXXX that return collections. This
is another area where performance is severely hampered.
I don't know of a perfect solution. If you can take advantage of CMP, some
containers will optimize (cheat) finder and bulk updates, or so I have read.
I don't code any of my bulk finders in the entity bean. This can cause some
duplication of db access code, or i can choose to abstract this code into
its own class. The way I see it, you have three choices.
1. Typically, the need to update many entity beans (bulk update) is not a
frequent occurrence. [This could be totally false in your case.] You could
remove the ability to update the specific bulk-update field(s) from your
entity bean, and require these fields to be modified through the session
bean only.
advantage: isolation of business rule, transaction integrity, speed
disadvantage: may require design change
2. Duplicate your business rule in the entity *and* the session bean. I
don't believe that this would be wise. It opens the possibility that the
session transaction can be affecting the underlying data of an entity, that
is also, engaged in a transaction. Some data would be lost. Strict isolation
levels on the database may prevent this...
advantage: speed
disadvantage: duplicate code, (potential) bad data integrity
3. Do it the slow way. Only update through entity beans.
advantage: isolation of business rule, transaction integrity
disadvantage: slow as molasses (relatively)
jim
----- Original Message -----
From: Masters.Robert <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 01, 1999 7:19 PM
Subject: Multiple Entity Updates and Performance
> Hi all, I have a problem :(
>
> I am curious as to the best approach to use when updating multiple entity
> beans. In our case there is denormalized data stored from tableA in
tableB.
> There also exists a 1 to Many relationship between A and B, thus if I
update
> A i am required to update multiple rows(entities) in B. My question
regards
> the best practice to use. As I see it I have two options:
>
> i. Entity Bean A (or its session bean wrapper) gets a enumeration
> of Entity B and updates each bean:
> advantage: all business rules for updating Entity B are preserved
> (if any)
> disadvantage: possibly performance hit creating all the EJBs
>
> ii. Session bean does a direct update to the database
> advantage: high performance
> disadvantage: breaks the model, no guarantee that business rules
(if
> any) are applied
>
>
> Obviously in a perfect world option i is the preferred solution. These
> entities I have created are quite large (course grained) and loading them
> involves allot of work (in some case multiple-table queries).
>
> What have people found when resolving this design problem??
>
> My system is an EJB set of components built onto a legacy (and somewhat
> denormalized) RDBMS schema (currently used by a COBOL business
application).
>
> (the above is a _very_ simplified overview of the actual problem)
>
> Regards
>
> Rob Masters
>
> Sun Certified Java Architect, Developer, Programmer
>
> Comcare Australia
> (w) 02 6275 0632
> (f) 02 657 4045
> [EMAIL PROTECTED]
> http://www.comcare.gov.au
>
>
===========================================================================
> 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".
