First, you are free to have seperate client threads access the same
instance of a SLSB via its remote interface. This will work fine.
However, I don't know why you would want to do that. One of the nice things
the EJB server is supposed to do for you is to manage the life cycle of its
beans. You are seeking to defeat that capability, which will reduce the
performance of your app. SLSBs are passed seemelessely from app to app by
the server so that a small number of them can serve a very large number of
clients.
You say your client wants to "cache" the bean. Does this mean that you are
assigning some state to the bean you want to maintain or top persist? If
so, this is not an appropriate use of a *stateless* session bean. I
recomend using a *statefull* session bean.
Good luck.
Jim
--On Wednesday, November 08, 2000 11:05 PM -0500 Vidur Dhanda
<[EMAIL PROTECTED]> wrote:
> I can't find a _definite_ answer to my question. Hopefully, someone can
> give me some pointers. Is it legal, per EJB 1.1, for multiple client
> threads to access a SLSB? Here's why this is important for me.
> Apparently, there is no portable way for a SLSB to tell a client that it
> has timed out. Hence, if a client caches a SLSB, it is prone to some
> "random" error. So, I figured, I will write a "keep-alive" thread and
> wrap the SLSB in an application object as a delegate. And in the SLSB,
> I will implement a no-op - ping(). Now, there's the possibility, that
> the SLSB will be in a method call when the keep-alive thread decides to
> do a ping. DO I need to guard against that?
>
> Thanks,
> Vidur
>
> --
> Vidur Dhanda
> Active Solutions
> tel: 617/566-1252
> [EMAIL PROTECTED]
> www.active-solutions-inc.com
>
>
