If you're going the sfsb route, then I can't think of anything better
than a Map from some id (perhaps the session id) --> SFSB handle.

However, as you point out, in a large system this Map could grow quite
large.

I would actually recommend a different approach. Create an entity bean
in the database for this shared data.

If you're concerned about the overhead of reading from the db, consider
using our optimistic caching support for entity beans.

http://edocs.bea.com/wls/docs70/ejb/...t.html#1159365

-- Rob


KRISH.VENKAT wrote:
> Hey Guys ,
>
> I have been away from the bea newsgroups for a long time, so am not sure if this
> group is being actively monitored...but want to give it a shot with an issue I
> am having ...
>
> I am having SFSB A , stateless B and stateless C
> Now there is a "common" SFSB D which has come up which A , B and C needs to invoke.
>
> I don't want to
>
> a) pass D as a handle in method parameters between A, B and C as any new session
> beans that come up will also need to access the "common" D
>
> b)I am trying to avoid persisting D for overhead considerations as that might
> mean doing a getMeDFromDB too many times.
>
> c) and if I start caching D's handle in a singleton memory , then our system could
> have around 500 concurrent users , so at any given time the hashtable(user-remoteHandle)
> could be huge..and I think it might not be a good idea to hold remote handles
> like that..!
>
> Is there a way in WLS70 where I could say within A, B or C that
>
> "give me the handle of D which has been created within this session context"
>
> Technically speaking this should be possible , as the container knows about this
> handle and is intelligent to passivate and activate it .
>
> How would you guys approach this ?
>
> Looking fwd for some insight..
>
> Thanx,
> Krish
>