2 questions in EJB

[james edwin]

Hi,
Just need small clarification :-
01) whethere there is only 1 EJBObject of a particular type which servers all the client request or for same type do we have multiple instance of it?
If multiple,then suppose at one time 200 clients are active,then that means 200 ejb Objects exists ?

02) how the Statefull session bean maintains the uniqueness of the client as it it does not use any mechanism such as cookie or some hidden parameter which are set by the client ?Which mechanism is used ?

[Andr? Wessel]

Hi,
1) it depends on the EJBContainer you use. Two kinds are common: one EJBObject instance, which is multithreaded, to serve for multiple bean instances. Or you will have for every bean instance an EJBObject instance, which is then single-threaded.
That sounds smart, doesn't it!? ;-) But I've cheated! I took it from the book "MasteringEJB2"(page68), which is free for download.
Greets, Andr�
2)

[Thomas Taeger]

Hi James,
I did not understand what "MasteringEJB2 (page68)" is to tell us but maybe I can answer some of your quetions:

Originally posted by james edwin:
01) whethere there is only 1 EJBObject of a particular type which serves all the client requests or for same type do we have multiple instance of it?

EJBObject is just an interface.
"... of a particular type" probabely means a remote interface - that allways extends EJBObject and will be implemented by a container-generated stub.
Yes, we have multiple instances of that remote interface:
- for session beans one session ejb per concurrent session/user,
- for entity beans one entity bean per "entity" (for example database table row) to be made persistent.

Originally posted by james edwin:
If multiple,then suppose at one time 200 clients are active, then that means 200 ejb Objects exists?

Yes, if for stateLESS session EJBs or for entity EJBs the poolsize has been set to be >= 200.

Originally posted by james edwin:
02) How the Statefull session bean maintains the uniqueness of the client as it it does not use any mechanism such as cookie or some hidden parameter which are set by the client ?Which mechanism is used ?

The uniqueness is maintained as the so called "state" of a stateFULL session EJB, i.e. as its [non-transient] member variables. If the pool is too small for holding all session beans, then an old one will be "swapped out" by the code that you provided in ejbPassivate() and later swapped in again by the code that you provided in ejbActiate().
ejbPassivate() of a statefull session bean writes its conversational state to a server-side storage (usually the hard disk), whereas cookies reside at the client-side and are not needed for stateFULL session beans.
Thomas.

[Rufus BugleWeed]

1. It does not matter to you. Often an EJB object has your bean as a delegate object. So if there are 1-to-1 instances or a multi-threading scheme it does not impact your functionality.
2. The client gets a home object and then creates a stateful SB. It's the client's responsibility to hold the reference. If you drop it, it's will be garbage collected eventually. If your end client is a web page served by a servlet or a JSP you might stash it in your HttpSession which is often connected by a cookie.
3. Mastering EJB 2.0 is a book by Ed Roman that was downloadable in non printable PDF format from www.theserverside.com to registrants. It may still be. I believe he wrote it after Monson-Haefel wrote EJB by O'Reilly and it compliments it.
[ January 29, 2003: Message edited by: Rufus BugleWeed ]

[Thomas Taeger]

Hi James again,
I had written and posted my previous reply too fast, sorry.
One passus that I wrote:

Originally posted by Thomas Taeger:
... by the code that you provided in ejbPassivate() ...

was just half the truth.
There are three tasks the container will do when passivating a statefull session EJB:
- It will serialize all serializable, non-transient member variables and write them to a cache on harddisk, i.e.:
- - 1) simple and many other data types like String being serializable anyway are automatically written,
- - 2) serializable compound datatypes are automatically written.

3) The container will call the ejbPassivate() method provided by you.
- This is your chance to handle non-serializable member variables like database connection or other resoures,
- - that are not serializable and
- - that you can not make serializable and
- - that therefore can not be written to cache but
- - that must be available after re-activation.
- These non-serializable member variables need to be treated speciallay:
- - declare them as transient because otherwise the container would throw an exception when trying to serialize,
- - initialize them in setSessionContext(sc) for example,
- - free them in ejbPassivate() by resetting these variables to null (!!) and
- - reallocate [and re-init] them in ejbActivate()
Thomas.
[ January 30, 2003: Message edited by: Thomas Taeger ]