Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

CMT and Stateless SessionBean

 
Morten Franorge
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is the scenario


If an exception occurs in doTransactionStuff, will the container do a rollback on the connection??
Or do I have to do the getConnection from the datasource inside the getConnection-method in the SuperClass / doTransactionStuff inside the SubClass?

[ August 03, 2005: Message edited by: Morten Andersen-Gott ]
[ August 03, 2005: Message edited by: Morten Andersen-Gott ]
 
seemapanth Joshi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whoa...I think it depends on lots of things. There is one whole chapter on exceptions and a separate one on transactions.

But first thing first, If you are going to catch "Exception e" and if you have a book called "Head First EJB" then the you can turn to page 544 and read on. This here is what they (the authors) are warning against is eating it up the runtime exceptions too.
 
Morten Franorge
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah I know. Did it this way to simplyfy the code. Not wanting to do catch all the exceptions in seperate blocks in the forum ;-)

What I'm really wondering about is whether connections retrieved from a ConnectionFactory will be rolled back if they are used within a method that calls setRollbackOnly. Asuming the ConnectionFactory gets the con from a datasource. (It won't use auto-commit etc...)
 
seemapanth Joshi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In that case the would not the answer be "yes", because setRollbackOnly() marks the "Current" transaction for rollback.

Also It would very much depend on what exceptions you are catching, because in case of system exception the container will automatically set the transaction for rollback. The "Current" one.
 
Morten Franorge
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure what you meant there? Would it be rolled back or not?
Keeping in mind the Connection is created in/retrieved from a ConnectionFactory...
 
seemapanth Joshi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Keeping in mind the Connection is created in/retrieved from a ConnectionFactory...


According to the specification you can get multiple connections from same resource connection factory object as you are doing in your abstract sample code. The point that you are making is I guess that since you are getting a new connection from the connection factory in the method call itself would the connection retrieved from this connection factory be affected by the rollback/commit. Spec 421-422


Invoke the appropriate method on the resource manager connection factory to obtain a connection to the resource. The factory method is specific to the resource type. It is possible to obtain multiple connections by calling the factory object multiple times.


I don't see that how would whether you create a new connection or use an cexisting one would affect the transaction management. Except I would like to know if <res-sharing-scope> will have some role to play if it is defined as Unshareable.

Am I making sense here?
 
Kay Ra
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
" If I have understood your question accurately"
his is what I think, it will be rolled back. If system error them automatically, if application error because you are catching it.
Secondly if system error then anyway your con object is useless for all you know it unrecoverable and the bean will be killed. So in the case of application error the con should be able to be used again. This can be tested by creating a scenario where at least an sql exception is thrown, may be specifing a wrong table name, then catch the sql expection, set rollback and try using the con oblect for a simple select.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Connection is unusable as the con variable is out of scope at the end of the try block.

Incidentally, this piece of code has a flaw: by failing to close the Connection, there is the danger of running out of pooled Connection instances.
 
Morten Franorge
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roger Chung-Wee:
The Connection is unusable as the con variable is out of scope at the end of the try block.

Incidentally, this piece of code has a flaw: by failing to close the Connection, there is the danger of running out of pooled Connection instances.


My mistake, the con should of course be retrived before the try-block, and closed if(con!= null && !con.isClosed()).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic