If you are using JSP, you could instantiate a bean using the USEBEAN syntax,
and specify application scope.
You could build a generic lookup class that could be a container for such
pick list items. Only the SQL would have to change.
Tim Gonda
PCSI - [EMAIL PROTECTED]
----- Original Message -----
From: "James Cook" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 08, 2000 4:35 PM
Subject: Re: Lists of items
> ----- 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".
>
>
>
===========================================================================
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".
