It's tough for container providers to provide Singleton behavior when more
than one JVM is involved;
I can trace this back to CORBA. That's why it's not in the spec.
JP
> -----Original Message-----
> From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> Sent: Martes, 30 de Enero de 2001 20:29
> To: Orion-Interest
> Subject: RE: Session EJB Accessibility
>
>
> I'm confused by your comments; does it need to manage state,
> or doesn't
> it? I'm assuming it does, otherwise you would just use a stateless
> session bean.
>
> Here's some fodder for conversation:
>
> I don't think there is an EJB facility which will help you. SLSBs are
> pooled and can timeout, SFSBs have no lookup mechanism, can
> timeout, and
> aren't reentrant (although Orion, despite the spec, serializes calls,
> which is good), and entity beans will get all wacky because of the
> multiple instances you will get from an optimistic concurrency model.
>
> It seems like what you want is either a SLSB which never times out and
> is guaranteed to only have one instance in the pool, or a BMP entity
> bean with a guarantee of serialized transactions.
>
> Is it possible to make Orion do either of these? And what
> would happen
> in a clustered solution?
>
> I propose that the only server-independent way to do what you
> want is to
> use an RMI server. The EJB specification really needs a
> "SingletonBean", preferrably one which allows concurrent
> calls (and thus
> reasonable performance).
>
> Comments?
>
> Jeff
>
>
> >-----Original Message-----
> >From: Mark Bernardinis [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, January 30, 2001 12:18 AM
> >To: Orion-Interest
> >Subject: Re: Session EJB Accessibility
> >
> >
> >I don't want to do any database activity. I just want this
> >Java Object to be
> >accessible as an EJB accessible by many different clients
> hosted by an
> >Application Server. The object doesn't have to be stateful either.
> >
> >> It sounds like you're describing an entity bean more than a session
> >> bean. An entity bean can be called by many clients although
> >access is
> >> serialized. And certainly the role of an entity bean is to
> >> encapsulate data in a
> >apparently-storage-mechanism-independent manner,
> >> from the client's perspective...
> >>
> >> How does the notion of a session play into what you want the bean
> >> to do?
> >>
> >> Gary
> >>
> >> Mark Bernardinis ([EMAIL PROTECTED]) wrote:
> >>>
> >>> Requirements:
> >>> An EJB to be Stateful
> >>> Accessible by more than client
> >>> Share the same data object and information
> >>>
> >>> Summarising the above information, I would like to have
> an EJB that
> >>> can be called by many clients yet share the same underlying data
> >>> within the bean. These clients may be another application running
> >>> under Orion or a stand-alone application.
> >>>
> >>> Is this possible, and if it is, what special requirements
> >do I need to
> >>> meet. I have looked at SessionContext but does this have
> anything to
> >>> do with it?
> >>>
> >>> Thanks in advance.
> >>>
> >>> Mark
> >
> >
> >
> >
>
