We've used this pattern to address several problems in our project. It seems
to work well, but you need to be careful as to when you use it -- especially
you should avoid this pattern if you genuinely want a unique "service"
across JVMs.
IBM has recommended this very approach for EJB development in VisualAge in
order to improve performance of Entity Beans which have associations between
them (p. 105-106 of redbook sg24-5754-00, on www.redbooks.ibm.com)
Essentially, if Entity Beans A and B have an association between them so
there is a method getB() on A's remote interface, then calling getB()
implies these actions:
1) using instance fields from A to obtain a primary key for the desired
instance of B
2) using B's home to call findByPrimaryKey(...) using the primary key just
obtained.
Step 2 is the problem, since by default the home interface of B is not
cached anywhere, and the JNDI lookup for the home is slow (not even the
initial context is cached). In order to cache home interfaces, IBM
recommends the use of a singleton holding a hashtable of home interfaces.
This singleton is a regular java class accessed by the EJBs. It should not
be an entity bean itself, since speed is the only reason for its existence
and we don't want it loaded from persistent storage every time it's
accessed. We don't care if multiple JVMs are running or not -- all we care
about is fast access within any given JVM.
-Charles May
===========================================================================
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".
