File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

transaction doubt

 
Aditya Vasudeva
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 85
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
tht question is very confusing indeed...

Anybody???
 
krishna bulusu
Ranch Hand
Posts: 185
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Vinay Nath
Ranch Hand
Posts: 85
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 329
Java Linux Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Vinay Nath
Ranch Hand
Posts: 85
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 28
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you for the clarification
 
Sergio Tridente
Ranch Hand
Posts: 329
Java Linux Oracle
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic