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".

Reply via email to