• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

query related to transactions ?

 
Ranch Hand
Posts: 924
1
Netbeans IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 138
Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Creator of Enthuware JWS+ V6
Posts: 3412
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 924
1
Netbeans IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3412
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 924
1
Netbeans IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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've got no option but to sell you all for scientific experiments. Or a tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic