• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Session Auto-Comit?

 
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

I have a session bean stateless defined with "transaction-type=container". So, does not matter which type of connection with database I have(pool, jdbc etc), my database transaction will be always atomic? because is inside of session bean method?

Thank's
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not quite. For instance, when dealing with distributed transactions the Tx Data Source must be enabled for 2-phase commit and an XA driver used.
 
Luciano A. Pozzo
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hummm.... but this is correct? I have to use a diferent type of datasource for work the session transaction control? I read on Mastering EJB:

"... the EJB container intercepts the request and starts a transaction automatically on behalf of your bean. That is, the container issues the begin statement to the underlying transaction system to start the transaction. The container then delegates the invocation to your enterprise bean, which performs operations in the scope of transaction. Your bean can do anything it wants to, such as perform logic, write to a database, send asynchronous message, or call other enterprise beans.If a problem occurs, the bean can signal to the container that the transaction must abort."

Can somebody clarify the things about session bean transaction?! please!

Thanks
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I will see if I can answer your question.

For transaction type, there are two settings, Bean managed and Container managed. For your SLSB, you are using Container managed transaction, which means the container is managing the transcation for you as indicated in the section of "Mastering EJB" you quoted.

With your transaction type setting, your SLSB will be bounded by a transction created by the container. Transaction begin when the method started and transction commit when the method ended. (Of course, unless rollback in the middle). So unless you are playing strange stuff with your database connection, your transction should be atomic. However it is not just because it is inside a session bean method call, but also because you are using Container manged transaction and SLSB.

Hope it help
 
Luciano A. Pozzo
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Abe....

Yes, I understand that this is the correct! The container manage the transaction, so should be atomic. But I tested with the method below! So when I update the database (oracle) and follow throw an Exception, the container don't rollback the update, so I have an inconsistency, because account2 will not be updated, and the account1 is updated. You know why this thing happen?

 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You must throw a system exception, not an application exception. Try throwing EJBException.
 
Luciano A. Pozzo
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hummmm.... yes, now worked, the database did not updated!

So... why only System Exceptions should thrown for work the transaction system? and another question: what can I do to solve this problem: if SQLException is thrown, the transaction will not happen again.. because is a Application Exception (SQLException is a Exception)....

But thank-you Roger, was great

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi..

System exception is something which cannot be recovered, so the continer will rollback the transaction. Container views application exceptions as an abnormal application-level condition, which typically can be recovered. So the container will not rollback the transaction, it tries commit...

So in such cases, you should explicitly mark the transaction for rollback using EjbContext.setRollbackOnly() method. Your code would look like this:

try {
// ---- do your db ops ---

} catch (SQLException e) {
// Mark the transaction for rollback..
sessionCtx.setRollbackOnly();

// If you want throw some appliation exception here..
throw new NotEnoughBalanceException();
}


- holla
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic