Java Beat Question - Q on transaction attributes

[Niranjan Deshpande]

@TransactionAttribute(REQUIRES_NEW)
public class BaseClass
{
public void method1() {...}
public void method2 () {...}
}
@Stateless
public class TestBean extends BaseClass
{
public void method1() {...}
@TransactionAttribute(MANDATORY)
public void method3 () {...}
}

What transactional attributes are available for the methods 'method1', 'method2'
and 'method3'?
a. MANDATORY, REQUIRED and REQUIRES_NEW
b. REQUIRED, REQUIRES_NEW and MANDATORY //How come b is correct? anything related to transaction attribute inheritace?
c. REQUIRES_NEW , REQUIRED and MANDATORY
d. None of the above.

[Joe San]

It is not transaction attribute inheritance, but rather simple Java inheritance,

Youe method 1 is overridden in your Session Bean and since you did not specify any transaction attribute, it is Required by default and for method 2, it is specified in the BaseClass to be Requires_New and for method 3, you explicitly say Mandatory.

Note: I guess this code will simply not work! How come you are annotating TransactionAttributes for a POJO like BaseClass??

[Treimin Clark]

Jothi Shankar Kumar wrote:How come you are annotating TransactionAttributes for a POJO like BaseClass??

It might be defined as an entity in the xml descriptor.

[Joe San]

But the original poster did not mention anything about it??

[Treimin Clark]

Jothi Shankar Kumar wrote:But the original poster did not mention anything about it??

Ya ya ya, just kidding.

[Raf Szczypiorski]

The code will work, your session beans may have base classes that are annotated, and their transaction attributes / DI annotations are considered. What you can't do, is specify transaction annotations on an entity bean, as Treimin said, it is invalid in the specs:
13.3.1:

A transaction management type cannot be specified for EJB 3.0 entities. EJB 3.0 entities execute within
the transactional context of the caller.

(Note this only includes JPA entities, previous entitnes in ejb 2.1 and earlier used CMT).

The answer is: method1 and method2 are REQUIRES_NEW, because the base class that defines them is. However, method1 is overridden in the bean, and the beans has default transaction attribute (REQUIRED), and so has method1. Method 3 is new, and it is explicitly set to MANDATORY.
But, there is never any interface specified, not by the implements keyword, or in the @Stateless annotation, so is this a valid bean at all? If it is not, there are no transaction attributes used anyways, as the container will not instantiate this bean... Correct me if I am wrong.

[Treimin Clark]

Raf Szczypiorski wrote:But, there is never any interface specified, not by the implements keyword, or in the @Stateless annotation, so is this a valid bean at all? If it is not, there are no transaction attributes used anyways, as the container will not instantiate this bean... Correct me if I am wrong.

One possibility: This TestBean class might be registered as a bean class in the descriptor, and it might also be registered as it's own business 'interface'. As same as to the annotation mappings below:

@Local
@Stateless
public class TestBean extends BaseClass{ 
....
}

[Promod kumar]

Going back to the original question (assuming the code is valid), does the answer change if BaseClass is a pojo versus a stateles session bean. It seems wierd that a pojo class is annotated with transaction attribute and those attributes are inherited. I was expecting the transaction attributes to be inherited only if the BaseClass is session bean. Can someone clarify.

[Ralph Jaus]

I think each annoatation (except @Stateless, @Stateful, @MessageDriven) that can be used in a bean class can also be used in superclasses of bean classes - correct me if I'm wrong.

Concerning the inheritance rules of transaction attributes see core spec 13.3.7.1. There'll find the example from above, too. By the way, for the exam it may be helpful to have this example in mind.

[Raf Szczypiorski]

Spec page 92 (4.6.2) makes this crystal clear:

The session bean class may have superclasses and/or superinterfaces. If the session bean has
superclasses, the business methods, lifecycle callback interceptor methods, the timeout call-
back method, the methods of the optional SessionSynchronization interface, the
Init or ejbCreate<METHOD> methods, the Remove methods, and the methods of the
SessionBean interface, may be defined in the session bean class, or in any of its super-
classes. A session bean class must not have a superclass that is itself a session bean class.

Hope this helps.

[Promod kumar]

Thanks Ralph and Raf for your input.
1) A session bean class must not have a superclass that is itself a session bean class.
(I read this multiple times before, but this never registered until now). I missed this completely.
2) The example in 13.3.7.1 does implement an interface unlike this example. So as Raf explained may be the bean is not valid, in that case the right answer here is d (none of the above)

[Niranjan Deshpande]

Even I had choosen D. Seems now, it's true 'java beat confuses you more' although it's OK to just browse the questions and answer them after your first read on the EJB3.0, you can not rely on it.

[Joe San]

But I remember trying this out by having a Session Bean subclass another Session Bean and it simply worked. I quite don't remember which container that was...but it clearly violated the spec and there is also a post that discussed this topic.

[Raf Szczypiorski]

For example, JBoss allows this. However, this is a SCBCD forum, and as far as the cert is concerned, they will only ask you questions that are clear and compliant with the specs. So, don't worry.

[Promod kumar]

EJB3 in action page 78, Section 3.1.3, 4th bullet

A session bean class can subclass another session bean or any other POJO.

This contradicts the spec

A session bean class must not have a superclass that is itself a session bean class.

I checked the errata for the book, did not find anything, Is this an error in the book.