I am using WAS 5 (EJB 2)
I would like to build a Search Session Bean that will invoke a finder method on a Entity Bean . the result might be larger then 100,00 DB rows.
should I trust the EJB container to handle this amount of data or should I do a BMP that limits the number of results or should I select first only the primery keys and then select only the rows I really use?!
Looks like you display all the search results but user may only touch a few records. You'd like the collection of basic data retrieved, and get each row you use later.
CMP and BMP all work if they do not optimize to get all the data in one SQL. Different containers implement differently on optimization. The safest way is to retrieve basic data (including primary key) in a stateless bean, and retrieve the beans you need later.
so , what you say is that EJB is bad for search that expexted large results?!
Just write a test-case to prove wich works better. EJB with BMP, CMP or a 'plain' jdbc call.
I would be interested in the outcome of this :-)
Do not use Entity beans for retrieving large ( even medium) collections of data, especially if it is read only data. You will get burned..(it takes more time, eats more resources and does unwanted transactional operations) trust me.Only go for entity bean if you need to support a transaction and/or you could cache all the beans effectively and/or need a a component that participates in create/modify/delete operations of database rows. Take a look at the fast-lane reader pattern in sun blue prints, its the way to go. (stateless session bean making JDBC call). If you (or your architects) insist, go for a coarse-grained composite entity bean.
Take a look at bitter ejb', available at serverside.com( why you don't build a logging object using Ejbs though it makes perfect sense)
"To EJB, or not to EJB: that is the question.
Whether 'tis nobler in the mind, to suffer
The slings and arrows of outrageous licensing;...."