Robert,
When you say, "The list statically caches the StateCode object(s)", do you
mean as a static variable? If so, this is a violation of the EJB spec. At
least, I think it is...
jim
----- Original Message -----
From: Masters.Robert <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 17, 1999 6:34 PM
Subject: Re: Singleton, Bean-managed Entity Bean, to lookup (mostly) Read-
only tables
> 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".
>
===========================================================================
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".
