|
|
|
|
|
|
|
|
|
|
|
|
|
When a client invokes the first method on the stateful session bean reference, the bean's life cycle begins. The container invokes newInstance( ) on the bean class, creating a new instance of the bean. Next, the container injects any dependencies into the bean instance. At this point, the bean instance is assigned to the client referencing it. Finally, just like stateless session beans, the container invokes any @PostConstruct callbacks if there is a method in the bean class that has this annotation applied. Once @PostConstruct has completed, the container continues with the actual method call.
Originally posted by Mirko Bonasorte:
Hi to everybody,
I've started studying EJB 3.0 and I have a doubt about stateless SessionBean pool: why should I have a lot of SessionBean instances even if they are stateless? Could not proxies invoke an unique SessionBean?
Thanks in advances
When a bean instance is servicing a request, the EJBContext takes on new meaning. The EJBContext provides information about the client that is using the bean. It also provides the instance with access to its own EJB stub proxy, which is useful when the bean needs to pass references to itself or to other enterprise beans. So the EJBContext is not a static class; it is an interface to the container.
Originally posted by Vahan Harput:
Hi all,
I have a question regarding the allowed operations in the lifecycle callback methods of stateful session beans:
On the page 80/81 of the EJB 3.0 core specification, it is specified that the PostConstruct/PreDestroy/PrePassivate/PostActivate lifecycle callback methods run in an unspecified transaction and security context. It is also specified that in such methods it is not allowed to access resource managers and other enterprise beans.
At the same time however, in the table 1 of page 79 accessing resource managers and enterprise beans is allowed for these lifecycle callback methods.
This seems to be a contradiction. Is this an error in the specification or am I missing something?
Best regards
The EJB specification does not prescribe how the container should manage the execution of a method with an unspecified transaction context�the transaction semantics are left to the container implementation.
Some techniques for how the container may choose to implement the execution of a method with an unspecified transaction context are as follows (the list is not inclusive of all possible strategies):
� The container may execute the method and access the underlying resource managers without a transaction context.
� The container may treat each call of an instance to a resource manager as a single transaction (e.g. the container may set the auto-commit option on a JDBC connection).
� The container may merge multiple calls of an instance to a resource manager into a single transaction.
� The container may merge multiple calls of an instance to multiple resource managers into a single transaction.
� If an instance invokes methods on other enterprise beans, and the invoked methods are also designated to run with an unspecified transaction context, the container may merge the resource manager calls from the multiple instances into a single transaction.
� Any combination of the above.
Originally posted by Kalyana Sundaram:
How to provide both Remote and local views to the same Session Bean?
There will be two different interfaces for Remote and Local client views. Do I need to add implements clause in my Bean class for both of these interfaces?
How to make use of annotations in this case?
Thanks in Advance !!!
A bean class is permitted to have more than one interface. If a bean class has more than one interface�excluding the interfaces listed below (java.io.Serializable; java.io.Externalizable; any of the interfaces defined by the javax.ejb package)�any business interface of the bean class must be explicitly designated as a business interface of the bean by means of the Local or Remote annotation on the bean class or interface or in the deployment descriptor.
The bean class must implement the interface or the interface must be designated as a local or remote business interface of the bean by means of the Local or Remote annotation or in the deployment descriptor.
While it is expected that the bean class will typically implement its business interface(s), if the bean class uses annotations or the deployment descriptor to designate its business interface(s), it is not required that the bean class also be specified as implementing the interface(s).
If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor.
The same business interface cannot be both a local and a remote business interface of the bean.
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/mydb");
