About Question enthuware.oce-ejbd.v6.2.611 :

[evefuji]

It must use bean managed transaction demarcation.

With @AccessTimeout does not work the requisites?

[admin]

No, @AccessTimeout is for any kind of operation, while the question question is specifically asking for Transaction.

[ramy6_1]

Hello ,

"A stateless session bean must either commit or rollback a transaction before it returns."

I don't understand why this statement make you select the last option , I mean from point 1 and 2 in the question itself why it has to be stateful not stateless ?

[admin]

Because statement 1 requires that two methods have to be called in the same transaction. A stateless bean cannot handle that. A stateless bean has to either commit or rollback a transaction after every method ends. So the same transaction cannot be used for another method call on that bean.

[pwang8]

"Both the methods will be called by the client in the same transaction scope."

Shouldn't this mean that the bean must be CMT because only BMT can call CMT? If client is in transaction, it can only call CMT bean.

[admin]

If client is in transaction, it can only call CMT bean.

Where did you read that?
-Paul.

[pwang8]

My bad. I had that notion for a long time. So a client in transaction can call a BMT bean but client's transaction is suspended when the BMT is called. Is that accurate?

[admin]

No, that is not correct. Suspension of the client's txn has nothing to do with bmt/cmt. It depends on the txn attribute of the callee (NOT_SUPPORTED).

[pwang8]

I am confused. I thought transaction attributes only apply to CMT. BMT is different.

1. From the spec
13.6.1 Bean-Managed Transaction Demarcation

"When a client invokes a business method via one ofthe enterprise bean’s
client views, the container suspends any transaction that may be associated with the client request."


2. From Frit's note:
5.4.3 Transaction Attributes Table Bean-managed

"A client transaction is always suspended when it calls a Bean-managed EJB (even if the client is another Bean Managed EJB)."

[admin]

You are right. I am sorry, I got confused. The client's transaction will indeed be suspended.

To answer your original question, "If client is in transaction, it can only call CMT bean.": No, that is not correct. A client can call BMT bean also. The question says that the client calls both the methods from the same transaction scope. It does not say that the bean methods will be executed in the same scope.

Let's say client has transaction T1, it calls method m1 on the BMT bean. In the BMT bean, transaction T1 is suspended. When m1 returns, the client's transaction T1 will resume and the client can call m2 in the same transaction T1. Of course, in m2, T1 will again be suspended, but that is ok.

I hope that is clear now and I apologise for the confusion.

HTH,
Paul.

[pwang8]

I had that wrong notion for as long as I can remember because we rarely use BMT. Thank you for helping me clear it up.

[himaiMinh]

Hi admin,
I understand why that session bean is a BMT from previous post.
But in the explanation, it says it cannot be a stateless bean as a stateless bean must commit or rollback a transaction before the business / timeout method returns.

But the question does not specify whether m1 or m2 commit or rollback before they return.

[himaiMinh]

Let me rephrase my question:
suppose T1 is the transaction started by a client,
is it possible that m1 commits its own transaction while T1 suspends and m2 commits its own transaction while T1 suspends?
After m1 and m2 commit their own transaction within the methods, T1 resumes.

In this case, the session bean can be either stateless or stateful.

[himaiMinh]

For everyone's reference:
I think the question :

both the methods will be called by the client in the same transaction scope.

is interpreted as m1 and m2 execute in the same transaction started by the session bean.

I think some candidates interpret it as m1 and m2 execute in the same T1, started by the client.

Which interpretation is correct?
1. m1 and m2 execute in the same transaction started by the session bean.
2. m1 and m2 execute in the same T1 started by the client.

I think the interpretation 1) is the correct one. Reasons:
1. user transaction is used in this case.
2. if a bean uses user transaction, this transaction will suspend the client's transaction. The bean will not execute in the transaction started by the client. Therefore, interpretation 2 is not possible.

I hope this analysis is correct and helpful for other people.

[aazizi.tarik]

@admin
you said :

Let's say client has transaction T1, it calls method m1 on the BMT bean. In the BMT bean, transaction T1 is suspended. When m1 returns, the client's transaction T1 will resume and the client can call m2 in the same transaction T1. Of course, in m2, T1 will again be suspended, but that is ok.

in that case why it must be a stateful session bean?! it may also be a stateless where the transaction will start and commit at the end! the question dosen't specify anything about that.

I think this question should be reviewed, thanks in advance.

[admin]

Because as per explanation to option 2, it must be a BMT and as per explanation to option 5, a stateless bean has to commit a transaction before it returns, which is not happening here. Therefore, it has to be a stateful session bean.

HTH,
Paul.

[aazizi.tarik]

@admin,

thats the point, you said "which is not happening here."? This is not specified in the question!

[admin]

The question clearly says that the methods are called in the same transaction. That means the transaction is not being committed after the first call. That is why it cannot be a stateless bean. A stateless bean has to commit or rollback the transaction at the end of the call, which is not happening here in this question.

[aazizi.tarik]

Do you mean that this will happen like that (I added what I understood in RED to you answer)

Let's say client has transaction T1, it calls method m1 on the BMT bean. In the BMT bean, transaction T1 is suspended. When m1 returns, the BMT transaction is suspended and the client's transaction T1 will resume and the client can call m2 in the same transaction T1. Of course, in m2, T1 will again be suspended, and the transaction started by the BMT when calling m1 will resume.

[admin]

Yes, as per section 13.6.1:

When a client invokes a business method via one of the enterprise bean’s client views, the container suspends any transaction that may be associated with the client request. If there is a transaction associated with the instance (this would happen if a stateful session bean instance started the transaction in some previous business method), the container associates the method execution with this transaction.

HTH,
Paul.

[aazizi.tarik]

Wow! clearly specified int he specs, thx Paul!

[henrid]

Interesting question. So this looks like having nested or overlapping transactions, but of course not active at the same time. Let me take the question a bit further, from what I learned in JPA. If the client is a servlet or other non-EJB, the client's transaction is not suspended, but propagated, even with BMT in the called bean, right? So in this case, all you may have is one BMT transaction from the client? And the callee may even be a stateless bean (if state is not important)? Never mind if this is not okay, but I am just curious.

[admin]

It can't be a stateless bean because as per section 13.3.3 - "Enterprise Beans Using Bean-Managed Transaction Demarcation", "A stateless session bean must either commit or rollback a transaction before it returns. "
Since the problem statement requires that both the methods will be called by the client in the same transaction scope, the bean method cannot commit the transaction.

[henrid]

I was talking about a propagated transaction from a non-EJB into an BMT bean, in case when transaction was started before the bean. But never mind.