Jim yes, I cache the objects for the list in a static variable. However, the
lists themselves ARE NOT EJB's. The lists are outside the scope of EJB. The
content of the list(s) may be populated by calling stateless session beans.
In effect you can consider the lists to be a client of the EJB as well as a
possible parameter to an EJB (an yep I deal with reconstruction the static
contents of the list during the de-serialisation of the list object if
required).
I am acutely aware that all static variables used in EJB (1.0) must be
marked final.
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: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: August 18, 1999 9:28
> To: [EMAIL PROTECTED]
> Subject: Re: Singleton, Bean-managed Entity Bean, to lookup (mostly)
> Read- only tables
>
> 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".
===========================================================================
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".
