The high-level question is: If I choose to manage persistence explicitly (instead of using CMP Entity Beans), what is the best solution using EJB? I don't see the value-added of BMP Entity Beans versus session beans that contain the JDBC code (1) My analysis, which may be faulty, is that the best alternative to BMP entity beans is a stateful session bean (analysis is in the next section). If someone can help me and show me where this is wrong, it would be much appreciated. (2) I haven't been able to determine how I can do the following in EJB: I want to be able to provide data caching: meaning, if 2 clients issue the same request to the database (with the same selection criteria) then I would like to avoid the second database hit if the first client's request is still in the bean. ===> NOTE: Long detail follows <===== Problem Defined: ================ I'm trying to decide how best to integrate relational db access with EJB. The general problem, using a specific example, is: My object model has a DeviceProfile object which contains information for a particular device type. The DeviceProfile data is persisted in 2 tables in a relational database: there is a 1-many relationship between the strong and weak entities (meaning, to retrieve the data for a device, one must perform a join on the 2 tables and get a list of records with the strong entity's fields being duplicated in the list). Clients want to be able to get a list of DeviceProfile objects by providing a list of identifiers (or 'keys'). Further, they would like to have methods that return this list in different formats: a) as a Collection of Java objects b) as XML. Insertion, update and querying of this entity are all supported. e.g. String deviceProfileObjectsAsXML = myObject.getAsXML(listOfDeviceIdentifiers); Here are the alternatives: ========================== 1. Stateless session bean (SSB) facade to BMP Entity bean w/ standard entity bean contract followed (Enumeration of Primary Keys returned by ejbFind). SSB accesses Entity beans and provides XML wrapping or pass-through for the Enumeration of Entity Beans. Analysis: PROS: a. client update (set/get) will result CONS: a. Database hit for each Primary Key; b. EJBObject/bean instance for each primary key; 2. SSB facade to BMP Entity that uses Fat Key pattern where ejbFind returns an Enumeration of pseudo primary keys that contain the PK plus the data for each record. SSB provides same functionality as 1 except that the returned collection/enumeration of deviceprofile objects are not Entity Beans; they are Java objects. Analysis: PROS: a. one hit to the database CONS: a. still have EJBObject and bean instance for each Primary Key; b. we have to process the data in a loop in the ejbFind() method and, then, if XML output is desired, the SSB has to process the data AGAIN; c. Data must be copied to/from EJBObject (via container). 3. Same as #2 except: the Entity bean puts all the data returned from the query into a single instance of a pseudo primary key. ejbFind() will parse the data and put it into the pseudo primary key. The ejbLoad() method will get the data from the EJBObject using the EntityContext. To avoid multiple processing in the SSB and the entity bean, we can have ejbFind() methods in the Entity Bean that return the data in the pseudo primary key formatted in XML. Clients can issue set/get methods with key information in order to set/get the correct db record. Analysis: PROS: a. one db hit (same as #2); b. one EJBOBject/bean instance (as opposed to multiple in #2); CONS: a. still have copying to/from EJBObject 4. Same as #3 except get rid of the stateless session bean and have client access the entity bean directly. Analysis: PROS: a. It seems like the stateless session bean is frivolous and not needed; otherwise, same PROS and CONS as #3. 5. Use a stateless session bean (and no entity bean) that performs the querying of the database. It has methods for getting the collection in XML format and as a collection of non-bean Java objects. Analysis: PROS: a. one db hit; b. one EJBObject/bean instance; c. no unnecessary copying/caching of data in EJBObject; d. No extra call to an Entity bean object. CONS: a. Client will interact with the non-bean Java objects and will be mistaken if the client thinks that by setting a value on the non-bean Java object that the db is updated. b. set/get methods (on the stateless session bean) with key info will result in a get from the db - no good. 6. Same as #5 except: use a Stateful Session Bean. Clients can then have the option of getting the whole collection as XML or getting the data items individually (with the stateful session bean caching the data. When client wants a specific row (object) from the db, it gets back a non-bean Java object that is a structure (not really an object). Client has to use session bean to get changes to the db. Analysis: a. Same benefits as #4; b. The CONS of #5 are removed. =========================================================================== 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".
