[Vasu]

Why are ejbActivate() and ejb Passivate() included for stateless session bean even though they are never required as it is nonconversational bean

To have a consistent interface, so that there is no different interface that you need to implement for Stateful Session Bean and Stateless Session Bean.
Both Stateless and Stateful Session Bean implement javax.ejb.SessionBean and this would not be possible if stateless session bean is to remove ejbActivate and ejbPassivate from the interface. You could argue that the two (stateful and stateless) are so different that they should have their own interface but Sun did not think so. They made both session beans implement the same interface and provided deployment descriptor to denote which one is it that you are deploying.

With EJB 1.1 specs, why is unsetSessionContext() not provided in Session Beans, like unsetEntityContext() in Entity Beans

ejbRemove() is called for session beans every time the container destroyes the bean. So you can use this method to do the stuff you typically would do in unsetEntityContext(). For entity beans ejbRemove() is only called if the user explicitly deletes the bean. I think that is the reason why the engineers at SUN invented the unsetEntityContext() for this kind of bean.

If my session bean with single method insert record into 2 entity beans, how can know that the process is done in same transaction (the attributes for these beans are Required)?

If your method in the session bean is already running under a transaction the calls to any other bean which have been deployed with trans-attribute \'Required\' will be executed within the same transaction context.
So if your session bean is using container-managed transactions and your method is deployed with \'Required\', \'RequiresNew\' or \'Mandatory\', you can safely assume that the calls to your entity beans are handled under same transaction. If you\'re not running in a transaction, a separate transaction will be set up for each call to your entity beans.
If your session bean is using bean-managed transactions, you can ensure that the calls are handled in the same transaction by :
javax.transaction.UserTransaction tran= null;
try{
tran=ctx.getUserTransaction();
tran.begin();
myBeanHome1.create(....);
myBeanHome2.create(...);
tran.commit();
}catch(...){}
You may want to check if you\'re already running in a transaction by calling tran.getStatus().

Is there a way to get the original exception object from inside a nested or wrapped Exception (for example an EJBException or RemoteException)?

Absolutely yes, but the way to do that depends on the Exception, since there are no standards for that.
Some examples:
·When you have an javax.ejb.EJBException, you can use the getCausedByException() that returns a java.lang.Exception.
·A java.rmi.RemoteException there is a public field called detail of type java.lang.Throwable
·With a java.sql.SQLException you need to use the method getNextException() to get the chained java.sql.SQLException.
·When you have an java.lang.reflect.InvocationtargetException, you can get the thrown target java.lang.Throwable using the getTargetException() method.

How can I retrive from inside my Bean (Stateless Session and Entity CMP) the user name which I\'m serving (the user name of user just logged in my web application)?

Inside an EJB you may retrieve the \"Caller\" name, that is the login id by invoking:
sessionContext.getCallerIdentity().getName()
where sessionContext is the instance of \"SessionContext\" (setSessionContext) passed to the Session Bean, or the instance of \"EntityContext\" (setEntityContext) passed to the Entity Bean.

Remaining answers for part 1 later

Post edited by: vasu, at: 2004/09/30 22:21