I'm trying to use EB as shared object.
It seems that it's up to the particular vendor to instantiate as many EB instances for the same PK as possible in order to optimise the performance of the container.
Is it possible to ensure only one instance of EB per PK at a time throught transactions configuration perhaps.
What ather alternatives for shared objects (the same instance can be accessed from different clients) in EJB?

Thanks.

I assume EB = Entity Bean.

EntityBean's are by definition shared/sharable objects.

Ignore what the container might or might not do, just use the EB as if you are the only client and that only one instance exists.

The container will manage the "sharing" of the EB by multiple clients, giving each client a transactional view of the EB.

Is there some reason why you want to insure only one active EJB instance?

Sorry for not explaning what did I mean by EB,
yes you've got it right EB = Entity Bean.

We need to have a component that absorbs messages from different Message Driven Beans (MDB) and reports some accumulative statistics in form of a message.
There is a debate among the developrs in my group if it should become an entity bean (even though it does not have to persist the data), how does the EB life cycle reflects the performance of the shared object, what are potential rase conditions, how well does it scale when the load goes up, and if there are some alternative solutions (design patterns perhaps).
Thank you for the relpy, it seems to clarify a lot of things for us.

Dmitry A.

You could have a start up class (most appservers have this feature) to "start-up" on server boot. The MDBs could call this startup class which accumulates the statistics.

Alternately, let the MDBs post to another Queue. Poll the queue from time to time and get your statistics.

If you don't mind a vendor specific solution, see if your vendor has a single JVM container. If so, you may choose to have a class with static attributes.

--Das