Vijay Dasari

Hey, HF EJB is lot better than HF book for SCWCD.....
But these books can be used as starters for a big feast ....
They are not complete references...

Vijay.

Hi,
According to Spec :-
The container can choose to passivate an entity bean within a transaction.
Before passivating it calls
1. ejbStore() ( which will be called within a transactional context)
2. ejbPassivate() ( this action does not really need a transactional context)

Where as a Stateful session bean will never be passivated within a transaction.

Vijay.

Hi Prasanth,
Thats an interesting question. I looked in to Spec, but i did not get the clear answer to that.

As i understood..
The Basic rule for ResourceManager access and Other Enterprise Bean acess is that the method(calling method) should be called atleast in a Transactional Context or it should have availability of the Security Context.

Wording from Spec
"
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.
"

The steps what a container might be doing for Enity Beans is

1. Bean(Enity) is in pooled state
2. Client calls a Business method.
3. Container picks an instance from pool
4. Container sets the PrimaryKey
5. Call ejbActivate() without any transactional context.
(At this point the bean instance is not yet identified with client.)
6. Container passes the Security context to the instance via EJBObject.
(Now the bean instance is identified with the client)
7. Call ejbLoad() with in the transactional context of the invoked business method.

Vijay.

Text from Spec:

Bean Provider:
=================
"The Bean Provider of an enterprise bean with container-managed transaction demarcation may optionally
specify the transaction attributes for the enterprise bean�s methods. See Subsection 17.4.1."

Application Assembler:
========================
"
Providing the transaction attributes for an enterprise bean is an optional requirement for the Application
Assembler, because, for a given enterprise bean, the Application Assembler must either specify a value
of the transaction attribute for all the methods for which a transaction attribute must be specified, or the
Assembler must specify none. If the transaction attributes are not specified for the methods of an enterprise
bean, the Deployer will have to specify them.
"

Deployer:
====================
"The Deployer is responsible for ensuring that the methods of the deployed enterprise beans with container-
managed transaction demarcation have been assigned a transaction attribute. If the transaction
attributes have not been assigned previously by the Assembler, they must be assigned by the Deployer."

Hi,

When a client calls a business method with in a transaction (clients tx),
the Container Behaves in two ways depending on the transactional attribute of the business method.

The Spec never says that TransactionRolledbackException wraps the original system exception in this scenario.

But in case of MessageDrivenBeans, they say that conatiner has to wrap the original exception.

Vijay.

Hi,

One of the ways a bean transitions from "Pooled State" to "Method Ready State"
is through ejbActivate() and you have access to getPrimaryKey() method but you can not use the setters and getters until the ejbLoad() method callback.

Here is what happens

1. Client calls a business method.
2. The container sees that it, does not have the bean instance for that entity in "Method Ready State"
3. It takes an instance from the pool.
4. Assigns the EJBObject(Context) to bean instance.
5. calls ejbActivate() , now you can acess the primaryKey of the Object instance.
6. Container loads the data from the database and sets the instance fields of the bean.
6. calls ejbLoad().

Vijay.

Application Assembler is responsible for setting the transactional attributes for beans.

It says MessageDrivenContext extends EJBObjet, whereas it should be MessageDrivenContext extends EJBContext.

For Stateful Session beans-
we know that the client maintains the life cycle of the bean, so we can have access to EJBObject in ejbCreate() method.

For Stateless Session Beans:-
The Spec says that "To the client, it appears as if the client controls
the life cycle of the session object. However, the container handles the create and remove calls without necessarily creating and removing an EJB instance".

So we can access the EJBObject in the ejbCreate() of the Stateless Session bean.

NOTE:
isIdentical(EJBObject ejbObject) will always return true for Stateless Session beans.