This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Java Beat Question - Q on transaction attributes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Java Beat Question - Q on transaction attributes" Watch "Java Beat Question - Q on transaction attributes" New topic
Author

Java Beat Question - Q on transaction attributes

Niranjan Deshpande
Ranch Hand

Joined: Oct 16, 2005
Posts: 1277
@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.


SCJP 1.4 - 95% [ My Story ] - SCWCD 1.4 - 91% [ My Story ]
Performance is a compulsion, not a option, if my existence is to be justified.
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9351
    
    2

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??


SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9351
    
    2

But the original poster did not mention anything about it??
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Jothi Shankar Kumar wrote:But the original poster did not mention anything about it??


Ya ya ya, just kidding.
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
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
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
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:

Promod kumar
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
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
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
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.

SCJP 5 (98%) - SCBCD 5 (98%)
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
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
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
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
Ranch Hand

Joined: Oct 16, 2005
Posts: 1277
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 Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9351
    
    2

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
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
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
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
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.



 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Java Beat Question - Q on transaction attributes