You hit the nail on the head. This is exactly what I want to do. I am
beginning to realise that maybe EJB is not the way to go with this example.
> 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.
>
This is exactly what I want to do. The only reason why I wanted to use EJB
was to get a bit more experience using them.
What I really want is many pooled objects that share one Master java object
so that any number of users can access the java object without being locked
out.
> 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
