questions?

[pradeep arum]

is the ejbCreate() in SLSB not in a transaction?
is there any way to know whether a particular method is in a transaction...if so how about the ejbCreate() in SLSB?
is it not a rule for a method to be in a transaction to access another beans methods & resource manager?
why can not we do the transaction rollback & check whether there is a rollback or not in SLSB ejbCreate()?

[Vishwa Kumba]

is the ejbCreate() in SLSB not in a transaction?
- NO, not in an meaningful transaction context.
is there any way to know whether a particular method is in a transaction...?
- AFAIK, there is no such method.Maybe future EJB Specs could include it. But we need to think, do we ever really need such a method in our EJB
API?

if so how about the ejbCreate() in SLSB?
- ejbCreate(), ejbRemove() for SLSB are meant to execute in an
unspecified transaction context.
is it not a rule for a method to be in a transaction to access another beans methods & resource manager?
- Yes, in a meaningful transaction context. In ejbCreate(), ejbRemove() we cannot have access other bean or resource manager like a database. We can only access the the bean instance's home reference, the bean instance's EJBObject and JNDI environment entries.
why can not we do the transaction rollback & check whether there is a rollback or not in SLSB ejbCreate?
- because ejbCreate() does not run in a meaningful transaction context.
In general ejbCreate(), ejbRemove(), ejbActivate(), ejbPassivate() and afterCompletion(boolean) methods of the Session beans execute in an unspecified transaction context,and hence have limited capability.
[ March 16, 2004: Message edited by: Vish Kumar ]

[Mrudula Madiraju]

Remember SLSBs lifecycle is under the control of the container? The container creates a bunch of beans and keeps them ready to process client requests. This implies that the ejbCreate is called by the container and that in turn explains why there is no transaction to be rolled back or to get the status.

[Vishwa Kumba]

Well, what is an "Unspecified transaction context"?
IMO, there are 3 types of transaction contexts in EJB:
1. No transaction context.
- We specify BMT for the bean's transaction type and do not open, close a transaction inside the bean methods.

2. Meaningful transaction context :
- BMT for the bean and open/close transactions inside the method. All the code inside the transaction boundaries run in a meaningful transaction context.
- CMT for the bean and methods have transaction attributes Required, RequiresNew and Mandatory.

3. Unspecified transaction context: (no meaningful transaction context!)
- CMT for the bean, and the methods have transaction attributes like NotSupported, Never or Supports.
- the ejbCreate(), ejbRemove(), setSessionContext, ejbActivate and ejbPassivate, afterCompletion methods of Session beans.
- setEntityContext, unsetEntityContext, ejbActivate, ejbPassivate of Entity beans.
- ejbCreate(), ejbRemove(), setMessageDrivenContext() methods of MDBs

To know more about the mystique "Unspecified Transaction Context", refer EJB2.0 spec, p:363, sec 17.6.5.
It has some good info.
Hope this helps!

[pradeep arum]

Hi Vish,
3. Unspecified transaction context: (no meaningful transaction context!)
- CMT for the bean, and the methods have transaction attributes like NotSupported, Never or Supports.
- the ejbCreate(), ejbRemove(), setSessionContext, ejbActivate and ejbPassivate, afterCompletion methods of Session beans.
- setEntityContext, unsetEntityContext, ejbActivate, ejbPassivate of Entity beans.
- ejbCreate(), ejbRemove(), setMessageDrivenContext() methods of MDBs
If this is the case.....then we should not be able to access the resource manager & other beans methods in the ejbCreate() of a SFSB because it does'nt have a meaningful transaction context,right?
but it is possible for a SFSB to access resource managar & other beans methods in ejbCreate()
can you explain stateful beans too...
thanks
Pradeep
[ March 16, 2004: Message edited by: pradeep arum ]
[ March 16, 2004: Message edited by: pradeep arum ]

[Vishwa Kumba]

Originally posted by pradeep arum:
If this is the case.....then we should not be able to access the resource manager & other beans methods in the ejbCreate() of a SFSB because it does'nt have a meaningful transaction context,right? but it is possible for a SFSB to access resource managar & other beans methods in ejbCreate()

Pradeep,
I am glad you have asked this question. This is a good one.
Surprisingly, the "bean-ness of SFSB is" contrary to SLSB for the container callback/life-cycle methods.

EJB2.0 Spec, p:81, sec 7.6.1
Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the Container does not have a meaningful transaction context or client security context.

So to access other resource managers or beans, we need to have a meaningful transaction context or a client security context.Please note that it is sufficient enough to have just one of them and not necessarily both of them. (for business methods, we have both contexts available)

SLSB's ejbCreate(), ejbRemove() methods neither have a meaningful transaction context nor a security context, hence it is not possible to access other resource managers or beans.

While SFSB's ejbCreate(), ejbRemove(), ejbActivate(), ejbPassivate() methods do not have a meaningful transaction context, but they do have a valid security context, hence it is very much possible to access other resource managers/beans for SFSB.

You may already be aware of this. Just to restate...

SLSB:
Whenever a client calls the create()/remove() methods of SLSB, the corresponding ejbCreate()/ejbRemove() may or may not be called by the container as the bean instances can be shared between multiple clients.So the bean instance cannot uniquely identify the client in the ejbCreate(), ejbRemove() methods.In other words, there is no valid security context available.

SFSB:
Whenever a client calls the create()/remove() methods of SFSB, the corresponding ejbCreate()/ejbRemove() methods will be called by the container as each bean instance is distinct to each client. Hence it is possible to identify the client in these methods with the methods getCallerPrincipal() and isCallerInRole().In other words, there is a valid security context available.
This is an important difference between SFSB and SLSB. The "bean-ness" of SFSB is different from "SLSB".

[pradeep arum]

thanks vish,
that was excellent point catched ...i liked it!!!
and now I need another clarification?
in entity beans ejbCreate() we can access resource manager/other bean methods and perform tx rollback/know whether a tx is rolled back or not
is it because we mean by a create() here we insert into a database? and to insert into a database the method should be in a meaningful transaction?
is this correct thinking?
thanks in advance
Pradeep
[ March 17, 2004: Message edited by: pradeep arum ]

[Vishwa Kumba]

Yes. You are right.There is a transaction attribute specified for ejbCreate() methods in the DD for CMT for Entity beans.
Again, the ejbActivate() and ejbPassivate() methods of Entity beans also have the same restriction. They cannot access other resource managers or enterprise beans, because neither there is a meaningful transaction context nor a client security context for these methods in Entity beans. These methods are called by Container and is quite transparent to the client.
As usual, both ejbActivate() and ejbPassivate() run in an "unspecified transaction context".

[Weerawit Maneepongsawat]

Vish Kumar thank you for your explain..That was very good..

[Ramakrishna Allam]

Helo Vish , I am really impressed with your knowledge in EJB . I wish i could be like you , but only in EJB knowledge. :-)
But let me know one thing . You said in case of CMT , you will mention the transaction attribute for ejbCreate and ejbRemove in the DD .And make it clear that is it for the create() , remove methods in the EJBHome and remove method in the EJBObject , that we mention the transaction attribute or to the ejbCreate() and ejbRemove() methods of the CMT bean ?

[Vishwa Kumba]

Originally posted by Ramakrishna Allam:
Helo Vish , I am really impressed with your knowledge in EJB . I wish i could be like you , but only in EJB knowledge. :-)

- I was also a beginner like you a few months ago, just hang around the ranch and apart from the certification, you'll also get some good knowledge.

But let me know one thing . You said in case of CMT , you will mention the transaction attribute for ejbCreate and ejbRemove in the DD .And make it clear that is it for the create() , remove methods in the EJBHome and remove method in the EJBObject , that we mention the transaction attribute or to the ejbCreate() and ejbRemove() methods of the CMT bean ?

- You are right. I admit I made a few typo mistakes up there in my post
We always specify transaction attributes for the methods of home/component interface. MDB happens to be a special case in which we specify the transaction attribute for onMessage() method of the bean class, as there are no home/remote interfaces.