aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes transaction doubt Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "transaction doubt" Watch "transaction doubt" New topic
Author

transaction doubt

Aditya Vasudeva
Ranch Hand

Joined: May 27, 2008
Posts: 76
according to enthuware, if a client (having a transaction) calls metha() of bean A [with a SUPPORTS transaction] and metha() calls methb() of bean B[with a NEVER transaction] and then methb() throws a system exception, the bean instance of methb() is NOT discraded.

Now, if a client (having a transaction) calls metha() of bean A [with a REQUIRES_NEW transaction] and metha() calls methb() of bean B[with a SUPPORTS transaction] and then methb() throws a system exception, the bean instance of methb() IS discraded.

The reason given in both cases is that methb() throws a system exception!!

Why does the bean instance get discarded in the second case and not in the 1st? Isn't it true that a system exception is being thrown in both cases???....

please help...
Vinay Nath
Ranch Hand

Joined: Jul 06, 2008
Posts: 85
tht question is very confusing indeed...

Anybody???


SCDJWS 5.0, SCBCD 5.0, SCWCD 5.0, SCJP 5.0
krishna bulusu
Ranch Hand

Joined: Aug 28, 2006
Posts: 185
Hi,

In first case, the method B is not in transaction and if it throws system exception, It won't effect the methods A transaction. Hence, the transaction continues.This means, Transaction can be committed irrespective of the exception thrown in method B.

In second case, method B and Method A both are in the same transaction. If Method B throws system exception, then the transaction of a would get effected. Here, the transaction 'can be' rolled back as both methods are in the same transaction.

In any case, the bean instance won't get effected. Might be the question is wrong. the transaction gets effected not the bean instance.
Please correct me if I am wrong.


Thanks&Regards, Krishna.
SCJP1.4, SCWCD1.4, SCBCD 5.0
Vinay Nath
Ranch Hand

Joined: Jul 06, 2008
Posts: 85
I also thought in the same lines but we cant be sure as thrs nothing in spec like this scenario... I think thrs a problem in this question...

one more thing we can think is tht this EJBException is thrown by the communication subsystem because of access problem due to transaction attribute and propagated back to method A() so its method A() which has to deal with it and bean B was not even involved. I read in spec smwhere tht even the comunication subsystem can throw EJBException.

in the second case, the call made it to bean B and exception had to be dealt by it, so it throws back to container and gets discarded.

I cudnt find any co-relation between transaction and system exception as an exclusive case.
Sergio Tridente
Ranch Hand

Joined: Mar 22, 2007
Posts: 329

I think B's instance gets discarded in both cases. Let's take a look.

First case:

Client (T1) --> A bean (T1) --> B bean (unspecified transaction context)

It is explained on Table 14 (section 14.3.1 of the spces). It corresponds to the case referred as "Bean method runs with an unspecified transaction context...", and the spec states clearly that the instance is discarded.


Second case:

Client (T1) --> A bean (T2) --> B bean (T2)

It is also explained on Table 14 (section 14.3.1 of the spces). It corresponds to the case referred as "Bean method runs in the context of the caller�s transaction...", in this case the spec says also that the instance is discarded.


SCJP 1.4 (88%) - SCJP 5.0 Upgrade (93%) - SCWCD 1.4 (97%) - SCBCD 5.0 (98%)
Vinay Nath
Ranch Hand

Joined: Jul 06, 2008
Posts: 85
I was just reading Mikalai Zaikin's notes for review and I figured out that I was right in my last post.

in the first case, its the method invocation (communication subsystem) that throws system exception to the container, so that why B is not discarded as the invocation didnt even reach it. The invocation caused the exception because before a method invocation complete successfully it has to see the context in which it is being called.

In the second case, its the method in B itself that throws exception which causes its removal.
E Lievaart
Greenhorn

Joined: Jul 06, 2008
Posts: 28
As far as I can see, in the first situation the container throws an exception,
because a method call with a transaction enters a bean with attribute NEVER.
This is not an error in bean B, but in the bean that calls it.
Bean A should not call bean B with a transaction.
It makes little sense to discard B, because it has done nothing wrong.
In fact, it has done nothing at all.

In the second situation bean B is invoked and something happens.
Bean B throws a system exception.
This is probably a resource problem or a programming error.
Since bean B might we corrupted it should be discarded.
Aditya Vasudeva
Ranch Hand

Joined: May 27, 2008
Posts: 76
thank you for the clarification
Sergio Tridente
Ranch Hand

Joined: Mar 22, 2007
Posts: 329

Originally posted by E Lievaart:
As far as I can see, in the first situation the container throws an exception,
because a method call with a transaction enters a bean with attribute NEVER.


I did not see that. It makes a lot of sense to me. It is the container and not B bean who throws the EJBException, thus B bean (which in fact it is not invoked) does not get discarded. As Vinay said, it is the communication subsystem that throws the system exception.

Thank you guys.
[ July 18, 2008: Message edited by: Sergio Tridente ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: transaction doubt