I had a similar situation, I encapsulated my list of objects into classes
using the ListModel interface from Swing.
Eg I have a StateCode object that can live in a StateCodeList object. The
list statically caches the StateCode object(s) which are either hard coded,
loaded from properties files or in the case where the database is the
repository - loaded from a stateless session bean (which simply supplies a
array of the appropriate objects for the requested list ie the stateless
session bean is a factory class, uses db connection pools etc so was
convenient to put it into a stateless session bean). In most cases the list
class can statically cached the list meaning you only need to retrieve it
once per JVM.
One could further this approach by selectively "flushing clear" the static
cache on certain list classes that would cause them to re-populate
themselves when next used. this is a nice approach as the list encapsulates
the ability to populate itself with objects of the required type.
Regards
Rob Masters
Sun Certified Java Programmer
Sun Certified Java Developer
Comcare Australia
(w) 02 6275 0632
(f) 02 657 4045
[EMAIL PROTECTED]
http://www.comcare.gov.au
> -----Original Message-----
> From: Jim Frentress [SMTP:[EMAIL PROTECTED]]
> Sent: August 18, 1999 0:11
> To: [EMAIL PROTECTED]
> Subject: Re: Singleton, Bean-managed Entity Bean, to lookup (mostly)
> Read- only tables
>
> use static methods in any java class you find convenient. where necessary,
> the static member variables are populated via jdbc. i see no advantage in
> using ejb for this.
>
> > -----Original Message-----
> > From: Murali Krishna Devarakonda [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, August 16, 1999 7:08 PM
> > To: [EMAIL PROTECTED]
> > Subject: Singleton, Bean-managed Entity Bean, to lookup (mostly)
> > Read-only tables
> >
> > Hi,
> > Will someone be kind enough to blow my idea to bits?
> > Or tell me that it does make sense:~)
> >
> > I have several read-only tables such as:
> > A. "States", "Countries", "ZipCodes", etc.
> > B. "genres", "moods", etc.
> > ... and so on.
> >
> > They are all Read-only for the most part. While modification of
> a)
> > is more rare than that of b), it's conceivable.
> > I have entity beans represented by a table in the database that
> > have
> > foreign keys pointing to tables
> > in A., like "User"
> > in B., like "Song"
> >
> > A form will need to provide the values from the Read-only tables
> > as
> > drop-down lists.
> >
> > The information in tables in A. and B., is frequently accessed,
> > shared by several "clients", and may(although very rare) need to be
> > modified.
> > So, I'm thinking I can have a ROTables Entity Bean(for want of a
> > better name:~), that's a singleton(created with a predetermined
> > primary-key(say, int pk=0, and not allow any other primary key), and
> that
> > supports methods like:
> > getStates
> > getCountries
> > getZipCodes
> > getGenres
> > getMoods
> >
> > etc.
> >
> > Are there any problems in this design? Is there a Better way to do
> > this?
> >
> > Thanks for your input.
> >
> > Regards,
> > Murali Krishna Devarakonda
> >
> >
> ==========================================================================
> > =
> > 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".
