Doubt in SessionBean contract(ejb 3.0 core)

[Senthil Kumar]

People are saying ejb3 is easier than its earlier versions.But as i am going through the specs, it proves to be the other way.It mainly because of i get
confused between the two versions.

1.A stateless session bean must not implement the SessionSynchronization i
interface.why is this?. Does this implies that stateless beans cannot
participate in transaction. i am sure they can have transactions.Then
please explain this.

2.Are these callback interceptor methods are mandatory.

3.In section 4.3.11 . Stateful session bean has one or move remove methods
why do we need more than one remove methods.

4.Here comes the major doubt.
Are there any differences the way in which container acts when we access
the session object
1. Through Dependency injection
2. JNDI lookup.

As of EJB3.0,
a)when we do a JNDI lookup what do we get as a result.Is it the referece to the stub of a EJBObject or something else?.

b) what does the Dependency injection gives?.

5. what is the significance of the methods getBusinessObject() and
getInvokedBusinessInterface().where they are useful
[ June 16, 2007: Message edited by: Senthil Kumar SS ]

[Shivani Chandna]

1.A stateless session bean must not implement the SessionSynchronization i
interface.why is this?. Does this implies that stateless beans cannot
participate in transaction. i am sure they can have transactions.Then
please explain this.

Read the following lines:

A stateful session bean class can optionally implement the javax.ejb.SessionSynchronization interface. This interface provides the session bean instances with transaction synchronization notifications. The instances can use these notifications, for example, to manage database data they may cache within transactions�e.g., if the Java Persistence API is not used.

In a stateless session bean the transaction has to start and commit within the business method call. It cannot span method calls. But for the stateful session beans the transaction can span multiple method calls. In that case it would be useful to cache data and clean up the data related to transaction spanning over multiple methods in the beforeCompletion or afterCompleted call.


Stateless session beans do not hold conversations and hence do not need these callbacks.

2.Are these callback interceptor methods are mandatory.

Mandatory to implement? If the SFSB doesnt implement the interface they are not.

3.In section 4.3.11 . Stateful session bean has one or move remove methods
why do we need more than one remove methods.

Great question Okay found the answer in Mastering EJB Book. The reason is with remove you can have the annotation/DD tag retainIfException.You may wish to create two methods one having retainIfException as false => so your bean will get removed if there is an exception and another with retainIfException as true => the bean will not get removed if there is an Exception and will be retained.

Are there any differences the way in which container acts when we access
the session object
1. Through Dependency injection (DI)
2. JNDI lookup.

If we use DI then we have the possibility to override annotation having the name of the injected bean reference using the DD xml.

JNDI lookup can be done using
(a) EJBContext :using the reference @EJB defined at the class level
we only need to specify the relative name and need not catch any checked exceptions.

(b) InitialContext: Need to specify the complete path to the resource and catch the checked exception (NamingException)

DI looks cleaner than using JNDI but DI is not supported for all classes. It is supported for servlets, beans.

As of EJB3.0,
a)when we do a JNDI lookup what do we get as a result.Is it the referece to the stub of a EJBObject or something else?.
b) what does the Dependency injection gives?.

I think internally EJB 3.0 annotations do the same thing as EJB2.1 otherwise compatibility would not be maintained....

5. what is the significance of the methods getBusinessObject() and
getInvokedBusinessInterface().where they are useful

getInvokedBusinessInterface() : A session bean can be exposed through three ways:
1. Business Interface (local/remote)
2. Component Interface (Local / Remote)
3. Web service end point.

This method helps in determining which interface was used to invoke the method on the bean.

getBusinessObject(): Instead of using this on the bean, which is not allowed - we use the api to send the current instance of the bean as a parameter to send to other bean's method calls. Or we can use this get the reference to the bean object in the client.

"For EJB 3.0 business interfaces the result of getBusinessObject() is semantically equivalent to the result of @EJB injection or explicit JNDI/EJBContext lookup. getBusinessObject is just a convenient way for a bean to get a business object reference to one of its business interfaces without having to define its own special ejb dependency"

[Senthil Kumar]

Using the lookup method in EJBContext can be useful only to find the objects
which are bound to a bean's private context.
But when we want to access a bean from a client like servlet , this will not useful. Am i right here. so we have to use the Initial context or DI.

where can i study the about DI(Dependency Injection). I do not find it in specs.

Then one common doubt,
Supposing if we instantiate a session bean object using new operator like we do in normal cases(inside a bean class), do we still get the containers special services like pooling,security etc.

[Senthil Kumar]

in continuation with the earlier doubts,

When the client calls a business method of the bean that has been designated as a Remove method, or a remove method on the home or component interface, the container invokes PreDestroy lifecycle callback interceptor method(s) (if any) for the bean instance after the Remove method completes.

waht do they mean by designated remove method here.As we know already if the bean class implements SessionBean then the ejbRemove only can be annotated as PreDestroy callback.
But why do we need to designate a business method as remove , when we already have a ejbRemove()/PreDestroy() for that.
[ June 18, 2007: Message edited by: Senthil Kumar SS ]

[Shivani Chandna]

Originally posted by Senthil Kumar SS:
in continuation with the earlier doubts,
what do they mean by designated remove method here.As we know already if the bean class implements SessionBean then the ejbRemove only can be annotated as PreDestroy callback. But why do we need to designate a business method as remove , when we already have a ejbRemove()/PreDestroy() for that.

Okay see there is difference between
:
@PreDestroy (EJB 3.0) aka ejbRemove (EJB 2.1)
and
@Remove (EJB 3.0) aka remove() on EJBObject (EJB 2.1)

Once Remove is called then PreDestroy is called.

If Remove has retainIfException as true and application exception is raised
then PreDestroy is not called as instance is not discarded.

Regards.