An entity bean is setup so that it corresponds to one row in the table. Suppose I want to read in 100 rows in the table and Iam using entity beans for this. What happens in this case? Will 100 entity beans be created and the references given back to me?Assuming this works, what happens when we try to read in 1000 rows? I would appreciate some answers
Hi, I'm not exactly sure if I'm right? But this is a general concern when considering between entity and session bean. For what I understand from reading is as follows. But first, to your question. In your case, your findByXxxxx method will return a collection instead of the EJBObject of the bean. The collection will consist of 100 EJBObject where you can refer to each row with each EJBObject. The concern is whether you need a method to retrieve 100 entity bean reference. If you're trying to display 100 record on a webbrowser, then use a Session bean and JDBC to fetch the 100 record. If there is certain relationship in transaction between these 100 record, then you have to use the 100 EJBObjects for the records. I guess in most case, you won't need that much of EJBObject in 1 transaction. Thus, probably on a couple or 10 EJBObjects in a transaction. So, for the guideline I've set for myself is. If the records is related in a single transaction, then use collection of Entity beans, else, use Session bean with JDBC. Comments? Cheers.
Finders return collections of primary key objects rather than the actual EJBs themselves. I'm ignoring single-instance finders, since that's not what interests you. The advantage of returning a collection of primary keys is that they are sufficient to locate the EJBs themselves, but usually consume a lot less in the way of resources. When you enumerate the finder collection, the EJBs are actualized. So in a really dumb system, each EJB would be created and activated at the moment you invoked the "nextXXX" method. Most appservers are smarter than that, however, and will be prefetching data and/or retrieving it from cache so that they can offer better performance. Despite this, I do recommend that wherever possible, you make intelligent finders. Even reduced overhead is still overhead.
Customer surveys are for companies who didn't pay proper attention to begin with.
so if I get this straigt, The Home object creates as much EJB objects as nescesarry and puts them in a collection. AS you move your way trough this collection, EJB's are activated and passivated from and to the pool with the data from the database (corresponding to the primary keys) ?
Real nice but, for example, is it smart to 'handle' 100,000 records this way ? Because creating 100,000 EJB objects might take some time, right ?
Hi: When you want to list many records in your JSP, it is better to use JDBC in your Servlet . So that you won't be creating that many entity beans. This design patter is called "JDBC for Reading" Rgds -Siva
It's really not a good idea to have servlets involved when you're talking 100,000 records - or even 10,000 records. No one is going to be able to read all that data anyway. You should either look for a more intelligent sort of retrieval or, if there's actually a NEED to work with that much data, you should put it in a batch process. Aside from the improved efficiency, you don't have to worry about doing the work in vain because the user's browser timed out while waiting for completion. Any intelligent EJB server isn't going to instantiate more than a certain number of EJBs are once. That number is often tunable, but since EJBs exists in RAM, there HAS to be an upper limit, or the system will crash. This is why the finders work with keys - since keys are almost always smaller, you can fit more into RAM. There is, of course, a noteworthy exception to the "limit your output" rule, and that is search engines such as Google, which build vary large lists very rapidly. But as far as I am aware, they're not using EJB technology for that, and their databases and algorithms are designed for fast read-only access with extgensive cross-indexing.