At 17:59 07.12.00 , you wrote:
>We're working on an ecommerce site which has a rather large (> 3M) record
>products table. We were hoping that the Collection which is returned when an
>entity bean's collection field getter is called would be smart .. that the
>entity beans would be instantiated as needed vs all instantiated at once.
>Alas, it appears that this is not the case. I initially ran out of memory
>trying to get the collection until I applied the
>ApplicationAdministrator.flushEJBCache hack, but the elapsed time is still
>just too large when dealing with that collection.
>
>My question is how are people handling this kind of problem? Should I just
>abandon CMP for this stuff and do it in a traditional fashion, perhaps a
>temporary table, via JDBC? Maybe cache the handles from the CMP collections
>for reuse? Go for a database specific solution?
IMHO you have to abandon CMP in that case as orion gives you no way to
configure the behaviour of a particular finder. in many cases orions way of
doing it (fetching all records) results in great performance but for 3M
that obviously hits a limit. I don't know which appserver gives you that
kind of control (I think inprise lets you decide whether a finder fetches
the data or just pks). It depends on the kind of client you use, what's
available as a solution. Probably the most robust way is using RDBMS
features like limiting the number of records in the resultset and perfom a
query against the db when the subset the client looks at changes. What do
you want to do? Just iterate over all or present a subset to a client (e.g.
browser or swing app) to select an entity?
regards,
robert
>tia
>
>john d
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
