Robert,
You are assuming an EJB implementation with a single JVM, and that the
Session Bean will be shared. Not a good assumption if you want to be
portable.
There is quite a bit on implementing Singleton's in the archive.
If you have an EJB server that provides for shared cache across JVM's, then
the shared cached data can be placed there, and any component can get to it.
Yes, this is a shameless plug for GemStone/J ;-)
-Chris.
> -----Original Message-----
> From: Masters.Robert [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, November 18, 1999 10:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Modelling Read Only Database Tables
>
> If the data is read only AND static in nature could you create a session
> bean but have the read only data defined as static final? this way you
> know
> the memory consumption in advance and being static you only have the
> overhead of the data per VM? I think I remember reading (EJB 1.0) that
> final
> statics are OK...
>
> Oh course this will NOT work if the data if volatile :(
>
>
> Regards
>
> Rob Masters
>
> Sun Certified Java Architect, Developer, Programmer
>
> 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: November 19, 1999 7:23
> > To: [EMAIL PROTECTED]
> > Subject: Re: Modelling Read Only Database Tables
> >
> > An entity bean of any type would be mucho-overkill for read-only data.
> >
> > 4. RMI Server - this would be the approach I would favor, unless you can
> > use
> > a CORBA server. Your server should provide a safe and convenient world
> for
> > this object, so you shouldn't have to worry about the issues you raised.
> > You
> > may not be getting these from your server vendor.
> >
> > 3. Stateless Session Bean - depending on how much information is in this
> > table(s), this can be a very nice way to go. Keep in mind that your
> server
> > will typically create the same number of stateless session beans as
> > dictated
> > by the maximum number of simultaneous client connections. That is why I
> > say,
> > the amount of data you are caching can become a concern.
> >
> > There is definitely a need for a singleton EJB object. I have described
> a
> > technique for making singleton BMP Entity objects in this group before.
> A
> > singleton stateless session bean could be very useful. Unfortunately, it
> > can't (?) exist the way the spec is currently written.
> >
> > jim
> >
> > ----- Original Message -----
> > From: Mihir Mehta <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, November 18, 1999 12:59 PM
> > Subject: Modelling Read Only Database Tables
> >
> >
> > > Hi EJB Gurus,
> > >
> > > What is the best way to represent read only database tables in EJB.
> > >
> > > I have following options :
> > >
> > > 1. CMP Entity Beans
> > > 2. BMP Singleton Entity Bean per table
> > > 3. Stateless Session Bean
> > > 4. RMI Server
> > >
> > > To me option 1 seems overkill.
> > > Option 2 seems ok, but I do not know how to make portable singleton
> > > entity beans.
> > > For option 3 I would like to get some idea on how to make a
> > > stateless session bean available to various clients efficiently.
> > > I guess with option 4 I would have to worry about the server crash,
> > > restart, and synchronization.
> > >
> > > I would appreciate if you would share some well established
> > > patterns, techniques and recommendations.
> > >
> > > Thanks,
> > > Mihir
> > >
> > >
> >
> ==========================================================================
> > =
> >
> > > 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".
