Stateless beans and SessionSynchronization

[Vipin Mohan]

hi friends

In HF EJB, it says that "Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."

I find this confusing because transactions don't span multiple methods in the case of CMT stateful session beans also. Then why is it that this interface can only be implemented by them ?

Thanks
Vipin

[Nathaniel Stoddard]

Stateful session beans may be BMT.

[Vipin Mohan]

But this interface can only be implemented by CMT stateful session beans.
Please advice.

Thanks
Vipin

[Suman Sarker]

I find this confusing because transactions don't span multiple methods in the case of CMT stateful session beans also. Then why is it that this interface can only be implemented by them ?

The SessionSynchronization interface provides the CMT session bean instances with transaction synchronization notifications. There is no need for a Session bean with BMT to rely on the synchronization call backs because the bean is in control of the commit. The bean knows when the transaction is about to be committed and it knows the outcome of the transaction commit.

[Vipin Mohan]

hi Suman

I know this point, my question is why it can't be implemented by stateless session beans. Anyway for both stateless and CMT stateful beans, transactions don't span multiple methods. Then whats the difference ?

Thanks
Vipin

[Suman Sarker]

Hi Vipin,
What I uderstand from your question

I know this point, my question is why it can't be implemented by stateless session beans. Anyway for both stateless and CMT stateful beans, transactions don't span multiple methods. Then whats the difference ?

is that the question has 2 parts

1. Why SessionSynchronization can't be implemented by stateless session beans?
2. For both stateless and CMT stateful beans, transactions don't span multiple methods. Then whats the difference?

Answer to Q1:
You have already come across the answer in HFEJB. Stateless session beans are not allowed to maintain a transaction once a method has ended.

Answer to Q2:
The difference is that when you use CMT in stateful beans, you need a way to figure out the status of the transaction. How will you know if the transaction is about to start, commit or rollback if you use CMT for stateful beans? The answer is you have no way to know that if you do not implement the SessionSynchronization interface. Remeber, in case of CMT, it's the Container that manages your transactions not you. So, you dont know the status of transaction unless the container tells you about it. By implementing the interface, you are instructing the Container to inform you about those notifications.

Hope this helps
Suman

[Ramesh Aiyappan]

Hi Vipin,

I assume your doubt is how a CMT stateful session bean can span transaction across method invocations.

A stateful session bean can span transactions even across different method invocations on the same bean.

Assume a client method, which invokes a method on the CMT stateful session bean (1.starts the conversation and a transactional state) and goes on to call different methods on the same bean (2.still holding the conversational state and the transaction) and then the method on the client ends (now the conversational state is closed and 3.the transactional state is committed).

Implementing the SessionSynchronization interface helps us to know when a transaction starts and ends (so we can do some CACHing on this).

You can get a clear picture of the stateful session bean holding the transactional state across method invocation in the same instance with a BMT stateful session bean.

In case of a stateless session bean the transaction starts and ends when the session bean's method ends.

Hope this would help.
Njoy.

[Vipin Mohan]

Dear Ramesh & Suman

Thanks for your answers. I have some confusion even now.
You have said that

A stateful session bean can span transactions even across different method invocations on the same bean.

However, on page 509 of Head First EJB, it is stated that
"CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Please advice.

Thanks
Vipin

[mini mehta]

Originally posted by Vipin Mohan:
Dear Ramesh & Suman

Thanks for your answers. I have some confusion even now.
You have said that

However, on page 509 of Head First EJB, it is stated that
"CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Please advice.

Thanks
Vipin

Hi Vipin

Don't you really hate when people are so patronizing. I don't understand why they are not able to understand your question, when it is clear from your initial post.

I have the same doubt, but sorry no answers yet.

Regards
Mini

[Suman Sarker]

Hi Vipin,
I think what Ramesh said

A stateful session bean can span transactions even across different method invocations on the same bean.

is only true if it were for beans with BMT. But, hey, we are talking about CMT beans here.
I think what you really want to know is why cant a stateless bean implement SessionSynchronization interface. Am I right?

Look, first of all you need to think of why we need the SessionSynchronization interface. The sole purpose of using this interface is to give a stateful bean a chance to synchronize itself with the persistent data it deals with. Now, you know that a stateless bean does not have any state for a specific client. So why would you want to synchronize itself with its persistent data?
Moreover, the stateful session bean does not go into the pool after it serves a method call from the client. A stateful bean is always serving a particular client but in case of stateless beans, the container does not guarantee that the bean that will be used on two method calls, will be the same. So even if you could synchronize a stateless bean, can you say it for sure that when you call the next method in your stateless bean, the Container will pick up the same bean from the pool that you synchronized? I dont see any point in using SessionSynchronization interface for stateless beans.
So, the answer to your question is there is no need for using the SessionSynchronization interface in stateless session beans. And the spec dictates that "A stateless session bean must not implement the javax.ejb.SessionSynchronization interface." even if it could.
Come to think of it.
Regards
Suman
[ June 14, 2004: Message edited by: Suman Sarker ]

[mini mehta]

Thanks Suman, that is what we were expecting, Good answer. I think you are right, because the Stateless session beans goes back to the pool after servicing a method request, there is no point in Synchronizing a Stateless session bean.

The key point here is that Synchronizing is done on the bean, not database.

When we use the Sychronising interface with Stateful session bean, it is just that that stateful session bean is given a chance to synchronize its own state. Ya sure, you can all sorts of things in those callbacks though.

[Vipin Mohan]

Thanks Suman !
But I still feel that I'm missing something about CMT stateful beans here.
The API states that
"The afterBegin method notifies a session Bean instance that a new transaction has started, and that the subsequent business methods on the instance will be invoked in the context of the transaction. "

But in Head First EJB, it is said that "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Don't you find these statements contradictory ?

And the statement "Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."
seems to support the first statement and contradict the second.

Can you advice ?

Thanks so much
Vipin

[mini mehta]

Originally posted by Vipin Mohan:
Thanks Suman !
But I still feel that I'm missing something about CMT stateful beans here.
The API states that
"The afterBegin method notifies a session Bean instance that a new transaction has started, and that the subsequent business methods on the instance will be invoked in the context of the transaction. "

But in Head First EJB, it is said that "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Don't you find these statements contradictory ?

And the statement "Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."
seems to support the first statement and contradict the second.

Can you advice ?

Thanks so much
Vipin

I guess you need to understand the fact that the SessionSynchronization is for Synchronise the Stateful session bean's own state.

[Ramesh Aiyappan]

Hi Vipin,

A Stateful Session bean, when serving a client can be in one of the two states, i.e. Method-Ready state or Transaction Method-Ready state, based on the transaction context with which it is invoked( With a transaction or with an unspecified transaction).

Whenever a method in the stateful session bean is invoked within a transaction, it will be in the transaction method ready state and can span transactions across method invocations on the same instance from the same client.

Lets say that the below is a method of a stateless session bean with transaction Required attribute ..

public .... someMthd(){
// Get the st8fulbn reference.
st8fulbn.invoke1() ;
st8fulbn.invoke2() ;
}

So this method is in a transaction and invoking the method 'invoke1()' in the stateful session bean propagates the transaction to the st8fulbn. (Have the stateful session bean implement the SessionSynchronization and have some log statements in it) you can see the afterBegin() method being invoked on the call to the first method, and when the someMthd() method ends, only then the transaction is committed and the 'beforeCompletion' and the 'afterCompletion' methods are invoked in the stateful Session bean.

Let me know if this helps.

Njoy,
Ramesh.

[Vipin Mohan]

hi Ramesh

Now its very clear to me. Thanks so much. But just want one last clarification from you. From your explanation, I understand that the following statement from Head First EJB is incorrect - "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Please do confirm this. Do correct me if I'm wrong.

Thanks again.

Vipin

[Suman Sarker]

Hi Vipin,

From your explanation, I understand that the following statement from Head First EJB is incorrect - "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

The statement is absolutely correct, let there be no doubt about it. If you read the statement carefully you'll notice that it says transactions cannot stay open across multiple method invocations from a stateful session client. The code sinppet that Ramesh showed is NOT from a session bean client. This code snippet resides in a bean. So, the bottomline is - transactions cannot stay open between method calls from a client but within a method inside a bean, you can use them in as many methods as you want.

Regards
Suman
[ June 15, 2004: Message edited by: Suman Sarker ]

[Vipin Mohan]

hi Suman & Ramesh

Isn't the stateless session bean a client of the stateful bean in this example ? A client can be any application or EJB which invokes the methods of the bean, right ? Do correct me I'm wrong here.

Thanks
Vipin

[Suman Sarker]

Hi Vipin,
First, I'll answer your question
Isn't the stateless session bean a client of the stateful bean in this example ? A client can be any application or EJB which invokes the methods of the bean, right?
Yes ofcourse, There is nothing to keep you from using a bean a client to another one (btw, MDBs dont have any cleints). And I am sorry that I could not explain it clearly in my previous reply.
Anyway, I'll try to explain the situation clearly in this reply. Ok here is how it all happens, for your clear understanding I'll continue to use Ramesh's example

Lets say that the below is a method of a stateless 
session bean with transaction Required attribute ..
 
public ... someMthd(){
// Get the st8fulbn reference.
st8fulbn.invoke1() ;
st8fulbn.invoke2() ;
}

Now, notice in the code that this stateless bean has the tx attribute of REQUIRED. This means a client(or may be another bean) starts the transaction by calling someMthd(). someMthd() will either start a new tx or continue to use the tx that the client passed on. Say the transaction for someMthd() is t1. (And what happens next is extremely important for you to understand the situation.) Next, someMthd() calls the invoke1() method of st8fulbn. The invoke1() method will also have its own tx attribute defined. Suppose, the tx attribute for invoke1() is defined as REQUIRED. so, the same tx (t1) will propagate to invoke1(). Notice that keeping transaction open in this scenario does not cause any harm because we are using the same transaction, t1. But what if the invoke1() had a different tx attribute? Consider the case when the attribute for invoke1() is REQUIRESNEW. Now we are in trouble, because while someMthd() is being executed in the context of t1, invoke1() tries to start another transaction t2. In this case we are keeping t1 open and at the same time trying to introduce another transaction t2. This will make the container freak out. Becuase this is nested transaction and the spec does not allow it. I believe this is what is meant by the satement "CMT transactions cannot stay open across multiple method invocations from a stateful session client."
I hope this clears all your confusions.

Regards
Suman
SCJP,SCWCD,SCBCD
[ June 16, 2004: Message edited by: Suman Sarker ]

[Vipin Mohan]

hi Suman

Thanks for the detailed explanation. However, I have a small objection. In this example, if the invoke1() method has a 'RequiresNew' transaction attribute, then the transaction of someMethod1() would be suspended and this transaction would proceed. Thats how 'RequiresNew' works, right ?

Thanks
Vipin

[Suman Sarker]

Hi Vipin,

In this example, if the invoke1() method has a 'RequiresNew' transaction attribute, then the transaction of someMethod1() would be suspended and this transaction would proceed. Thats how 'RequiresNew' works, right?

Yes that's exactly how "RequiresNew" works unless we are into a situation in the described scenario of my last reply. Lets see what the spec says about ur question (EJB spec p82 sec 7.6.4)

If a session bean instance is participating in a transaction, it is an error for a client to invoke a method on the session object such that the transaction attribute in the deployment descriptor would cause the container to execute the method in a different transaction context or in an unspecified transaction context. In such a case, the container throws the java.rmi.RemoteException to the client if the client is a remote client, or the javax.ejb.EJBException if the client is a local client.

What this really means is that the Container will throw an exception if the client's transaction t1 remains open in someMthd() and we go about using another transaction t2. But the Container will not throw any exception if someMthd() had the tx attribute "RequiresNew". What you said in your reply about the "RequiresNew" attribute is true in the latter case. Finally I would like to conclude it in this way -

Scenario 1
-------------------------------------------------------------------
client -> someMthd1() [Required]client -> someMthd2() [RequiresNew]
-------------------------------------------------------------------
 
Scenario 2
-------------------------------------------------------------------
client -> someMthd1() [Required] -> invoke1() [RequiresNew]
-------------------------------------------------------------------

Container will not throw any exception in case of scenario 1, but it certainly will throw an exception if are in scenario 2.

I think this is how it all works. If anyone else has some other arguments, please share it here. And Vipin let me know if I made it clear this time.

Regards
Suman

[Vipin Mohan]

hi Suman

Thanks so much for explaining, now I understand what you mean here. But I think that the problem would happen only if the bean is currently participating in a transaction and you try to start a new transaction in the same bean.
For example,

client -> Bean1's someMthd1() [Required] -> {
Bean2's invoke1() [Required]
Bean2's invoke2() [RequiresNew]
}
In this example, Bean2 is made to start a new transaction, while its already in an open transaction. Now there will be an exception, since nested transactions are not allowed.

But in your example,

client -> Bean1's someMthd1() [Required] -> Bean2's invoke1() [RequiresNew]

I think Bean1's transaction is suspended when it calls Bean2's invoke1 method. So the same bean won't have to start a new transaction when one is open.

What do you think ? Whatever you answer might be, my original question has now been answered. The only question left is whether your example will cause an exception or not.

Thanks a lot
Vipin

[Suman Sarker]

Hi Vipin,
Thank you for pointing out the problem in my example. Yes, I agree the example I showed in the scenario was an inappropriate one. But I think I have been able to help you understand why the statement in HFEJB is correct.
That's all.
Regards
Suman

[Vipin Mohan]

hi Suman

Yes, now I'm clear with the whole concept, thanks to you and Ramesh.
It was a very useful discussion.

Thanks again for your time.

Cheers
Vipin

[mini mehta]

Originally posted by Vipin Mohan:
hi Suman

Yes, now I'm clear with the whole concept, thanks to you and Ramesh.
It was a very useful discussion.

Thanks again for your time.

Cheers
Vipin

Hi Vipin

Now that you have understood it, can you please explain in simple terms why

"Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."

Mini

[mini mehta]

Hey Vipin

Can we have response from you please.

Mini

[Sati Sidhu]

Sorry guys, but i'm still very confused with the following post:

Thanks Suman !
But I still feel that I'm missing something about CMT stateful beans here.
The API states that
"The afterBegin method notifies a session Bean instance that a new transaction has started, and that the subsequent business methods on the instance will be invoked in the context of the transaction. "

But in Head First EJB, it is said that "CMT transactions cannot stay open across multiple method invocations from a stateful session client."

Don't you find these statements contradictory ?

And the statement "Only stateful session beans can implement SessionSynchronization, because stateless session beans are not allowed to maintain a transaction once a method has ended."
seems to support the first statement and contradict the second.

Can you advice ?

Thanks so much
Vipin

Kathy can you please shed some light on this topic as your the person who wrote the first statement. I rather hear it from the horses mouth!

Can you also provide an example of the following statement in the spec:

If a session bean instance is participating in a transaction, it is an error for a client to invoke a method on the session object such that the transaction attribute in the deployment descriptor would cause the container to execute the method in a different transaction context or in an unspecified transaction context. In such a case, the container throws the java.rmi.RemoteException to the client if the client is a remote client, or the javax.ejb.EJBException if the client is a local client.

Thanks,

Sati

[Sati Sidhu]

Kathy's reply to my question:

Howdy -- yes I think this is VERY confusing because of the way we
worded it. We should have added that this applies only to transactions
that START in the stateful bean, rather than the client.

For example, imagine a client calls a method on a stateful bean that is
marked with a transaction Required. The Container starts the
transaction, but the transaction MUST end when the method completes.
But using BMT, the stateful bean can start a transaction, but then not
close it at the end of the method (and instead wait for another method
invocation on a method that DOES end the transaction -- a really bad
idea).

Now, what was confusing I think is that you are right that if another
bean starts a transaction and THEN calls a method on the stateful bean,
and that bean is using CMT, then the bean that originated the
transaction does not cause the transaction to start, and so the
transaction can stay open while the originating bean keeps calling
methods on that same stateful bean.

So, that bullet point refers ONLY to transactions that originate in the
bean itself. A CMT transaction that begins with a bean's invocation
must *end* when that method completes. But a BMT transaction can be
started in one of the stateful bean's methods and then ended in a
different method of that same stateful bean.

Does that help?

Cheers and sorry about the confusion!