EJB Server client sessions are established internally by the client stubs and proxies that applications use to invoke EJB Server component methods. A component’s lifecycle determines how instances are allocated, bound to client sessions, and destroyed. EJB Server manages both client sessions and component lifecycles without requiring specialized knowledge on the part of the application developer.
Internally, the stub or proxy object establishes a network connection between the EJB Server and a remote client. The stub/proxy model discussed in “Client stub/proxy support” requires user-authentication parameters to instantiate a stub or proxy object. The communication protocol is also determined when the stub or proxy object is instantiated. Once the stub or proxy object exists, all details of network communication are hidden from the application developer.
All stubs and proxies use the Inter-ORB Invocation Protocol (IIOP) to communicate with the EJB Server. See “Network protocol support” discusses client protocols in detail.
For more information on stub and proxy objects, see Chapter 7, “Creating Enterprise JavaBean Clients.”
In the simplest case of lifecycle management, an instance is allocated for each stub or proxy created by the client and is destroyed when the client explicitly requests destruction or when it disconnects, whichever happens first.
More sophisticated components can be coded to support instance pooling. Instance pooling allows EJB Server to maintain a cache of component instances and bind them to client sessions on an as-needed basis. Instance pooling requires the following changes to your component:
The component must provide activate and deactivate methods. EJB Server calls the activate method just before an instance is bound to a client session. activate must be able to reset the component to an as-allocated state. EJB Server calls deactivate just before an instance is unbound from a client session (that is, made idle again).
Methods in the component must use the EJB Server transaction state primitives to request early deactivation.
For components that support EJB Server transactions, the time between EJB Server’s activate and deactivate calls coincides with the beginning and end of that instance’s participation in an EJB Server transaction.
Using components that support instance pooling increases the scalability of your application. Instance pooling eliminates execution time and memory consumption that would otherwise be spent allocating unnecessary component instances.
EJB Server supports multiple coded character sets for clients and components. When a client and component use different coded character sets, the EJB Server automatically converts character data from one character set to another. For example, if the client uses the roman8 character set and the component uses iso_1, EJB Server converts string parameters and return values automatically from roman8 to iso_1 when the client calls the component methods.
In accordance with the Java standards, Java components use 16-bit Unicode. Unicode contains mappings for all characters in all other known coded character sets.
EJB Server and its host Adaptive Server must use the
same character set. If you change the character set on Adaptive
Server, you must perform a similar change on EJB Server. See “Configuring an EJB Server”.
