You've pretty much laid out the alternatives. There are a few errors in your
analysis though. See below.
--Victor
May Charles N wrote:
> All right, I've got this CMP pattern which keeps recurring. If this is
> common say so, but I haven't seen others' solutions to it. I've got a few
> proposed solutions and would like feedback. I'm working in VisualAge for
> Java 3.5.2.
>
> Beware before you send suggestions -- using BMP is NOT an option here. I
> need a CMP solution.
CMP doesn't excluded using database code in bean methods.
>
>
> The problem occurs when there are two CMP entity beans in a 1-many
> relationship and a CMP attribute in one bean is dependent on the other
> bean's attribute(s) or number of instances. For example (this is ONLY an
> example to illustrate the concept by analogy), Employer and Employee are in
> a 1-many relationship, and Employer has persistent attributes numEmployees
> and totalEmployeeSalaries.
>
> Now use these definitions for the calculated attributes in Employer:
> numEmployees = number of employees linked to this employer
> totalEmployeeSalaries = sum of salaries for all employees linked to this
> employer.
>
> Here are some solutions regarding these attributes and what I see as their
> pros and cons:
> ---------------------
> 1) Remove setter methods from Employer's remote interface. Make the getter
> methods in Employer actually calculate their values each time they're
> called.
>
> pro:
> -attribute values are always "correct" in EJB space when Employer's getter
> methods are called
>
> cons:
> -wastefully slow computations and loads when there are many Employees. If
> there are thousands of employees, every time getTotalEmployeeSalaries() is
> called on Employer ALL fields of ALL the corresponding Employees must be
> retrieved from the database, adding only ONE of the retrieved fields for
> salary to the sum, and discarding everything else.
This isn't necessarily true. Why wouldn't you use Select count(*), sum(salary)
from Employer
where ...? Either the CMP engine should do this or if it's not capable, you
could put the code in ejbLoad or the getter methods.
>
> -attribute values can be wrong in the database. If an employee's salary
> changes (using either its EJB remote interface or directly using SQL), the
> employer's totalEmployeeSalaries field is not automatically updated. If an
> employee is added or removed, the employer's numEmployees field is not
> automatically updated.
This will be true no matter what scheme or language you use. If you do the sum
then change the list you've summed, the result will need to be updated. Not
particularly an EJB problem.
> If reporting is being done using SQL, the reported
> values are not guaranteed correct.
Don't understand the problem here. The database should be up-to-date an the
completion of the transaction. Until the transaction is committed you don't want
the changes reflected in your report anyway.
===========================================================================
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".
