Hi Gene:
Would you use EJBs on future projects? Once you opt against using entity
beans, do EJBs provide a sufficiently good cost/benefit ratio relative to
alternatives (e.g., RMI, CORBA)? To me, it seems like the middle-layer,
clusterable, data cache is one of the hardest parts of an app server ... if
you have to do it yourself why bother with an app server?
Laurel
-----Original Message-----
From: Gene Chuang [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 30, 2001 1:06 PM
To: [EMAIL PROTECTED]
Subject: Re: DB in EJB: stateless/stateful sessions vs BMP Entity vs BMP
E ntit y with Fat Key
My Fat Key pattern was initially a BMP counter-response to CMP bulk-loading
optimization provided by many vendors (BEA in specific). However, we here
at Kiko have been slight disenchanted with EJBs in general; a majority of
our architecture now consists of SSB hitting JDBC. But middle-tier
data-caching is still a high-priority concern of ours!
We here, Lawrence being the principal author, have come up with an abstract
middle-layer, clusterable, data cache we call ClusteredExpiryCache. (I have
hinted of this pattern in another thread I posted regarding JMS and
thread-safety). This pattern's expiry method is similar to Dimitri's
Seppuku pattern:
http://dima.dhs.org/misc/
However, unlike Seppuku, which depends on WL's propietary ReadOnly entity
EJBs, our ClusteredExpiryCache is EJB- and vendor- independent.
Our new architecture is still undergoing refinement, as we just pushed it
out to production on our site last week. In the near future Lawrence will
most likely publish his baby on theserverside or this newsgroup, so stay
tuned!
Gene Chuang
Kiko.com
-----Original Message-----
From: Bill Leonard [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 27, 2001 11:31 AM
To: [EMAIL PROTECTED]
Subject: DB in EJB: stateless/stateful sessions vs BMP Entity vs BMP
Entit y with Fat Key
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".
===========================================================================
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".
===========================================================================
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".
