aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes query related to transactions ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "query related to transactions ?" Watch "query related to transactions ?" New topic
Author

query related to transactions ?

gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

on page 312 enterprise java beans 3.1 book says

The getRollbackOnly() method returns true if the current transaction has been marked
for rollback. This information can be used to avoid executing work that would not be
committed anyway. For example, if an exception is thrown and captured within an
enterprise bean method, getRollbackOnly() can be used to determine whether the exception
caused the current transaction to be rolled back.
If it did, there is no sense in
continuing the processing. If it did not, the EJB has an opportunity to correct the problem
and retry the task that failed. Only expert EJB developers should attempt to retry
tasks within a transaction. Alternatively, if the exception did not cause a rollback (i.e.,
getRollbackOnly() returns false), a rollback can be forced using the setRollback
Only() method.


in the above paragraph , i am not able to understand the bold lines i..e how can getRollBackOnly be used to determine whether the exception caused the transaction to be rolled back ? Please help ranchers
Prajakta Acharya
Ranch Hand

Joined: Nov 08, 2012
Posts: 138

As per my understanding, it is this scenario:
1) An EJB has some method which does some business operation and starts the transaction.
2) This method calls another method from say another bean and the same transaction is used by that method. (As you know, appropriate annotations for the method being called (method 2) will ensure this).
3) Now, if some runtime exception is thrown by method 2, then the container marks the transaction for rollback because since method 2 is also part of the same trasaction, if it fails, the transaction should not commit.
4) Since it marks the tx for rollback, container must be calling tx.setRollbackOnly(true) on that tx.
5) So, when method 1 executes tx.getRollbackOnly() and if it returns true, that method knows that the transaction is not going to commit due to some exceptional condition, and there is no point in proceeding further.

Of course, we will wait for experts to comment on this and validate this understanding.


Regards,
Prajakta
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1674
    
  25

Hi,

Well explained, a couple of remark though:
- setRollbackOnly() is called on the EJBContext (not on the transaction)
- as method 1 on bean 1 catches an Exception (thrown by method 2 on bean 2) it will check whether the transaction is marked for rollback

Important concepts to grasp:
- an Exception doesn't rollback a transaction (the container does)
- if an Exception is thrown it doesn't necessarily mean that the transaction is "marked for rollback"
- if a transaction is rolled back (by the container) it will only happen in the bean where the transaction was started (by the container)

Regards,
Frits
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

thanks for the reply but it did not clear my original doubt.

Doubt 1 - suppose a bean 1 calls bean 2 method . bean 1 method is running in a transaction that gets propagated to bean 2 method. now if a system exception occurs , container will MARK TRANSACTION FOR ROLLBACK.does mark transaction for rollback means container automatically calls EJBContext.setRollbackOnly() method ?

Doubt 2 - will EJBContext.getRollBackOnly() returns true for both when container marks transaction for rollback and when the bean provider do EJBContext.setRollBackOnly() ?

Doubt 3 - how can getRollBackOnly() tell me that exception say X caused transaction to be rolled back ? it can be possible that no exception occurred but bean provider invokd EJBContext.setRollBackOnly method. in this case also getRollBackOnly will return true.

Doubt 4 - Frits , couldnt understand your last point viz. "if a transaction is rolled back (by the container) it will only happen in the bean where the transaction was started (by the container) "?
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1674
    
  25

Doubt 1 - suppose a bean 1 calls bean 2 method . bean 1 method is running in a transaction that gets propagated to bean 2 method. now if a system exception occurs , container will MARK TRANSACTION FOR ROLLBACK.does mark transaction for rollback means container automatically calls EJBContext.setRollbackOnly() method ?

Correct

Doubt 2 - will EJBContext.getRollBackOnly() returns true for both when container marks transaction for rollback and when the bean provider do EJBContext.setRollBackOnly() ?
Yes, I guess you don't mean bean provider, but business logic of a certain bean calls EJBContext.setRollBackOnly(), right?

Doubt 3 - how can getRollBackOnly() tell me that exception say X caused transaction to be rolled back ?

getRollBackOnly() only tells me if the current transaction has been "marked for rollback" (indeed not related to an exception, but we were discussing the case that an exception was thrown)

Doubt 4 - Frits , couldnt understand your last point viz. "if a transaction is rolled back (by the container) it will only happen in the bean where the transaction was started (by the container) "?

The container can not rollback the transaction in Bean 2 because the transaction was started in Bean 1. I just meant to say that rollback is initiated at the same place as where the transaction was started.

Cleared all you doubts?

Regards,
Frits
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

Doubt 2 - will EJBContext.getRollBackOnly() returns true for both when container marks transaction for rollback and when the bean provider do EJBContext.setRollBackOnly() ?

Yes, I guess you don't mean bean provider, but business logic of a certain bean calls EJBContext.setRollBackOnly(), right?


from bean provider I meant ejb developer who has coded the specific bean. right ??


and I'm still not able to get the last point. i'm reiterating

The container can not rollback the transaction in Bean 2 because the transaction was started in Bean 1. I just meant to say that rollback is initiated at the same place as where the transaction was started.


My thoughts - if system exception occurs , the container will rollback the transaction. what does initiating at the same place as where the transaction was started signify ? the changes that were made to resource managers in bean 2 will also be rolled back, right ?? can you give a short example Frits ?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: query related to transactions ?