----- Original Message -----
From: WHITESIDE, CHIP <[EMAIL PROTECTED]>
> How are people handling static lists of items such as countries, states,
> business types, etc? It seems that these would need to be cached somehow.
There are a variety of techniques with advantages and disadvantages.
1. Stateless Session Beans
On many systems, these beans will (or can) be set to never expire. There
should also never be more SLSB in the system than the number of simultaneous
users. Usually, this is a relatively small number. As with most static
lists, there are times that the list will need to be refreshed. You will
have to implement some mechanism for letting the session bean know that its
static list has changed. This could be as easy as a method or use something
more complex, such as JMS.
* more instances than are truly necessary
* could lead to excessive memory usage
* may behave very differently on different servers
* follows the ejb paradigm
2. CORBA object
If you are using an app server that is based on CORBA, it probably supports
the ability to act as a container/repository for pure CORBA objects. With
this nice perk, you can create a true singleton object (if you wish...one
per VM would probably be sufficient), that houses your static data. Also,
there is no difficulty notifying the bean to refresh.
* may not be supported by container
* not ejb-based
* very efficient and fast
3. Cheat - Static variable
Although it is not exactly allowed by the spec, you may wish to encapsulate
your static list directly in the bean(s) that need it. You do this by
initializing the list as a static variable in the bean class that needs it.
You could also use a helper class, if the list needs to be shared among
various bean classes. Technically, you are not violating the current spec if
the data is going to remain read-only. This blows the "periodic refresh"
principle, but most EJB containers do not *prevent* you from implementing
this non-spec behavior.
* potentially not very spec friendly
* generally considered the "quick and dirty" approach
good luck,
jim
===========================================================================
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".
