<vendor>
A shared cache behind any of these techniques will work best. That way you
can use a Session Bean to front end the cache, and you don't duplicate any
data.
</vendor>
-Chris.
> -----Original Message-----
> From: James Cook [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, November 18, 1999 3:23 PM
> 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".
