Chris,
I don't agree. I currently use an architecture where we have a cluster pool
of RMI servers that our clients connect to. Although they do not need to
communicate between themselves, they do individually use static methods/data
for all the objects they instantiated. We are a candidate for EJB if just
to replace our load balancing architecture.
Why do you believe that individual EJB servers couldn't benefit from static
methods/data?
-Ron
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> Sent: Tuesday, October 26, 1999 5:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Singletons (offshoot of EJB Restrictions-- threads, io)
>
>
> What you should consider is that statics depend on class loader semantics
> which are not appropriate for distrbuted architectures that EJB
> is intented
> to serve. If you only need a single server JVM for your server
> objects, you
> probably aren't a candidate for EJB anyway!
>
> -Chris.
>
>
> > -----Original Message-----
> > From: Ron Yust [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, October 26, 1999 5:53 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Singletons (offshoot of EJB Restrictions--
> threads, io)
> >
> > You mean in order to use the equivalent of simple static global
> variables
> > I
> > have to create an entity bean or use Corba and JNDI? Crazy! The more I
> > get
> > into EJB, the more the dream fades and a nightmare begins.
> >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook
> > > Sent: Tuesday, October 26, 1999 3:40 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Singletons (offshoot of EJB Restrictions-- threads, io)
> > >
> > >
> > > Theory
> > > ==========
> > > You can achieve "singletons" in EJB by using a BMP entity bean.
> > > Override the
> > > findByPrimaryKey object to always return the same primary key
> > > value. Do not
> > > provide a create method.
> > >
> > > Caveat
> > > ======
> > > 1. An EJB container is not required to create a single instance
> > > of an entity
> > > bean per container. Many of the more scalable implementations will not
> > do
> > > this. They rely on the underlying database to provide synchronization
> > > through isolation levels. Even if the container *does*
> > > synchronize access to
> > > a single instance of the entity bean, multiple containers housing the
> > same
> > > bean will create multiple instances. Therefore, this does not
> result in
> > a
> > > *true* singleton object, although it may be suitable for your needs.
> > >
> > > 2. The transaction overhead usually associated with entity
> beans is not
> > > often desirable.
> > >
> > > Solution
> > > ========
> > > Don't use EJB to implement singletons. I would create a remote
> > > CORBA object
> > > and bind it in the JNDI namespace. Sure, I end up implementing my own
> > > lifecycle management (or my CORBA container does), but we've been
> > > doing that
> > > for years before anyone heard of EJB.
> > >
> > > jim
> > >
> > > ----- Original Message -----
> > > From: Ara Abrahamian <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, September 23, 1999 1:50 PM
> > > Subject: Re: EJB Restrictions-- threads, io
> > >
> > >
> > > > As far as I know only entity beans and JNDI contents are shared,
> > > > session beans don't. But entities are persistent. Suppose I want
> > > > to have something like a "static activeUsersList" in a bean and act
> > > > as a true singleton object, only one instance avialable.
> > > > How can I "cleanly" implement it?
> > > >
> > > > Ara Abrahamian
> > > > bi!
> > >
> > > ==================================================================
> > > =========
> > > 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".
