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

[ETS User]

The explanation in the fourth answer is this:

Only stateful session beans can do so in their ejbCreate() methods. Stateless session beans can do so only in their business methods because their ejbCreate() and ejbRemove() do not have a meaningful client transaction context or client security context.

Also singleton beans do so. Perhaps it should be added.

[admin]

Singleton beans are new to 3.1 They don't have ejbCreate.

[deadlock_gr]

Duh, yes, you are right...

[Christian]

Option 2

All session beans can call SessionContext.setRollbackOnly().

is actually not wrong.

All session beans can call SessionContext.setRollbackOnly(); however, enterprise beans with bean-managed transaction demarcation will get an java.lang.IllegalStateException. Nevertheless, nothing is preventing you from calling setRollbackOnly().

If the question were

All session beans can safely call [...]

, I'd agree with the provided answer.

This is different from Option 1

All session beans can access javax.transaction.UserTransaction

, where you will not get access to the UserTransaction instance if the enterprise bean has container-managed transaction demarcation.

[admin]

Well, when you say "can call", it implies that you expect the call to be successful. It is like saying, "can you call System.exit() from a bean?" Of course, you can. Nothing is preventing you from calling it. But since it is not allowed by the specification, it would be valid to say, "you cannot call System.exit() from a bean."

Or "can you compile this code(that has a typo, for example)?". Of course, you can. Just that you will get an error. Would that make sense?

HTH,
Paul.

[Christian]

Hi Paul,

thanks for your quick reply. I am usually not that pettifogging, but since the tool itself is, I thought, I'd give it a try

I respectfully disagree with your System.exit() example. I'd say you can call it, but "you shall not". I would not even use "must not" (just a gut feeling).

I think "can" sometimes implies (may imply) a successful outcome, and sometimes it may not. But this differs from context to context and from person to person. Let's not get philosophical and leave it.

Best regards
Christian

[admin]

OK, I see your point. We will incorporate your suggestion to avoid this confusion.
thank you for your feedback!

[IndoKnight]

I would say the answer is the first one

To prove, I have the below program running on JBoss7.1.1 application server

Code: Select all

import java.util.concurrent.Future;

import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import javax.ejb.AsyncResult;
import javax.ejb.Asynchronous;
import javax.ejb.Remote;
import javax.ejb.Stateless;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.transaction.SystemException;
import javax.transaction.UserTransaction;

@Stateless
@Remote(AdvCalculatorRemote.class)
@TransactionManagement(TransactionManagementType.CONTAINER)
public class AsyncCalculatorBean {
	
	@Resource
	private UserTransaction ut;
	
	@PostConstruct
	private void init() throws SystemException{
		System.out.println("In AsyncCalculatorBean:init()");
		System.out.println("UserTransaction : "+ut);
		System.out.println("UserTransaction status : "+ut.getStatus());
		System.out.println("Successfully completed @PostConstruct");
	}
	
	@Asynchronous
	public Future<Double> asyncMultiply(double a, double b){
		System.out.println("In asyncMultiply, multiplying...");		
		double result = a * b;		
		System.out.println("Return result "+result);
		return new AsyncResult<Double>(result);
	}
		
	public double multiply(double a, double b) {
		System.out.println("In multiply, multiplying");
		return a * b;
	}

}

and below is the output when I invoke asyncMultiply(double, double) method

Code: Select all

18:14:47,784 INFO  [stdout] (EJB default - 10) In AsyncCalculatorBean:init()

18:14:47,785 INFO  [stdout] (EJB default - 10) UserTransaction : org.jboss.tm.usertx.client.ServerVMClientUserTransaction@1c7d2e3

18:14:47,786 INFO  [stdout] (EJB default - 10) UserTransaction status : 0

18:14:47,786 INFO  [stdout] (EJB default - 10) Successfully completed @PostConstruct

18:14:47,787 INFO  [stdout] (EJB default - 10) In asyncMultiply, multiplying...

18:14:47,787 INFO  [stdout] (EJB default - 10) Return result 12.0

Why the answer is not the first one?

[admin]

Because the specification says so. Please see section 4.3 of EJB 3.1 specification.
I have no idea about the code you've quoted but it is possible that JBoss is not complaint in this case.

HTH,
Paul.

[IndoKnight]

Thanks Paul.

It'll be great if you can point me where it is mentioned in the spec, so we see the same thing.

The spec says you can't use getUserTransaction on session context, which is true even in the example I provided. If I had used context.getUserTransaction() I would have got exception. But, please note that I got access to UserTransaction using dependency injection.

Cheers

[admin]

On page 96, it says:

The UserTransaction interface is unavailable to enterprise beans with container-managed transaction demarcation.

So it doesn't matter whether you use dependency injection or do getUserTransaction. End result is the same. CMT beans are not allowed to use UserTransaction.

HTH,
Paul.

[himaiMinh]

It is true that if a bean is using container transaction management, we can do SessionContext.getUserTransaction and UserTransaction.begin or commit inside a business method.
However, when we execute this bean's method in GlassFish 3.1.2, we will see IllegalStateException as user transaction is not supposed to be used in a CMT bean.