Sachin Aggarwal wrote: >Say we have instantiated a bean representing the collection of say 'Item' >beans and return a remote reference to the client. When the client asks for >some info on the list of items, then is the assumption that the collection >bean has a list of references of the item entities but it iterates over them >on the server side and returns a list of data objects to the client? I don't necessarily agree with this assumption that the item is an entity bean. Entity beans are not intended for objects which are merely an OO representation of the database - there is supposed to be significant "Business Logic" in them. You haven't said what an "item" really is, but on the assumption that it is something like an order item or a shopping basket item then the order or the shopping basket will have the business logic in it (eg to calculate discounts, merge items requesting the same part, or give 3-for-the-price-of-2 offers) and the order item is little more than a data object and does not justify being an entity bean. >Assuming this is true, then when the client makes a new call to the same >colection bean in a new transaction but wants different data from the same >collection of item entities, then won't that require that the collection >bean reload all the item entities ? *unless* the item entities are still >cached! > >Looks to me like for this scenario where we are querying the same >collection, the caching of beans becomes important and the idle time for the >entity beans needs to be set high enough that they don't get passivated. > >So would you agree that caching can be an issue even when the server returns >objects by value to clients? Yes. It's always important. You can cache the objects and avoid going to the database for objects in your cache if (a) you have exclusive use of the database from the single object environment your application is running in or (b) your database and object cache support full cache coherency (but no RDBMS supports this yet as far as I'm aware - maybe the OODBMSs do???). Otherwise rely on database caching and try to ensure that your EJBLoad method is efficient. One way to do this, using the shopping basket example again, is as follows: * Design the application so that a shopping basket, including all items in the basket, is an Entity Bean, * Within EJBLoad, instantiate the Basket Entity Bean by an SQL call on the "Baskets" table to load information about the basket, and an SQL call on the "Items" table to load all items in the basket. * as processing of the basket within the transaction proceeds, load the individual items into simple objects (we could call them sub-entity beans) as needed and maintain a "write-back list". * Within EJBStore write back the state of objects in the "write-back list" to the database. Yes I know this can't be done with CMP, and I know that it embeds some messy details of persistence into the methods on the bean, but its the only way, within the EJB framework, that I can see to solve some real problems. <soapbox> If you'll allow me to use your question as an excuse for drawing together a number of threads on the mailling list, I'd say that: 1. Agressive local optimisation of inter-bean calls that violates the EJB spec (as done by Weblogic) 2. Smart Proxies (as per Rickard Oberg's package) 3. Anticipatory loading of entity beans (not sure who claimed to do this - I think it was Gemstone) 4. My hack above are all attacking different aspects of the same problem, namely the granularity of object models vs the granularity of architected server-side objects. The ideal solution, in my opinion, would be to allow every object in the model to be an efficiently callable CMP "sub-entity bean" and to compose sub-entities at deployment time into coarse-grained entity beans working approximately as I described above. Unfortunately "sub-entity beans" are not yet architected. </soapbox) Ian McCallion CICS Business Unit IBM Hursley [EMAIL PROTECTED] Tel: ++44-1962-818065 Fax: ++44-1962-818069 =========================================================================== 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".
