Sanjay Nambiar wrote:
> As Chip Wilson pointed out I wanted to use the finder method with an extra
> attribute in the entitybean of Table 1 (Collection Type) and a similar
> approach in Table 2 .
> The question is whether I could query the table2, from table1 entitybean
> itself; and populate the extra attribute of Table1 as mentioned above i.e
Yes, there's no problem with SQL querying table2 from table1 entity bean.
> the attribute would contain the bean references of all the records retrieved
> from Table2.Then using an iterate I could get the records of Table2 from the
> session bean for each record of Table1.
However what you'd get back would be the PKs - which are not object references,
and you would need to use a finder to turn the PK into a reference, so it's not
clear what you gained by issuing the SQL query in the first place.
> Here I would like to point out that I am NOT using a CMP Bean but bean
> Managed Persistance. Additionally the real time data volumes of the tables
> mentioned are very high. So performance is an other Problem.
> DATABASE:Informix
>
> Richad,Rickard,Ian any Pointers.......of a better solution????
Regarding performance/alternative solutions, you do not say on average how many
objects at one level "hang off" objects at the higher level, and you do not say
whether (a) all of the table2 and table3 objects hanging off a particular table1
object are needed every time a table1 object is instantiated, or whether (b)
only a few are needed. These seem to me to be essential factors in the design.
In case (a) it is quite possible that there will be a severe performance problem
using Entity Beans for all table2 and table3 objects, because as has been stated
often here, entity beans are not lightweight objects. For the sake of argument
let's say it turns out to be too expensive to use entities for table3. Then you
could design the table 2 entity bean to store the results of an SQL query on
table3 as an attribute of the table2 entity (You are already using BMP so this
is not too big a leap). To preserve object orientation you could use the GOF
Flyweight pattern for table3 objects. Table2 bean would need interfaces for
answering the session bean's questions about table3, but this may be goodness
(in the Demeter sense) in that the session bean is no longer dependent on the
detailed data object structure.
In case (b) you might find that using a finder in table2 objects to obtain only
the needed object references references to table3 objects performs fine. However
if the filtering of table3 objects cannot be expressed as an SQL query you might
need to revert to the suggested approach for case (a) or use some hybrid
approach to ensure lazy instantiation of table3 entities.
Ian McCallion
===========================================================================
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".
