This week's book giveaway is in the HTML Pages with CSS and JavaScript forum.
We're giving away four copies of Testing JavaScript Applications and have Lucas da Costa on-line!
See this thread for details.
Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

"Bean Things" in afterCompletion()

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In afterCompletion() you cannot call setRollbackOnly() or getRollbackOnly(), because the transaction has completed. Also you cannot access another enterprise bean or a resource manager. Page 512 of Head First EJB says "You can't do any tranaction-related things because you're no longer in a transaction. You can access ONLY your special JNDI context. It's not safe to access resource managers or other beans."
I've just been reading the spec Transactions section, and thought I understood a bit more about accessing resource managers, and how the container includes access to other resources (databases and JMS resources) within an existing transaction, so it seemed to make sense that you can't access a resource manager (and maybe another bean) from afterCompletion() because it's never within a transaction.
But then I remembered that a session bean's ejbCreate(), ejbRemove(), ejbActivate() and ejbPassivate() run in an unspecified transaction context, and we know that a bean is not passivated if it is in a transaction, so we know that ejbPassivate() will not have a transaction. But while these four methods don't allow calls to setRolbackOnly() and getRollbackOnly(), they *do* allow access to resource managers and other beans, which implies that the ability to do these things is not related to being in a transaction.
Does anybody understand why the rules are different for afterCompletion() and the four ejb* methods? I'm trying to understand why, rather than just memorise a table of what's allowed. Is the ability to access another bean and a resource manager really related to being in a transaction? Is there something I've not understood?
 
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know the answer but I can relate to your frustration. During my exam preparation there were a lot of concepts that I had to accept on face value. I find it much easier to retain information when I know why it is. Besides, I have a very curious nature that compels me to know what makes things tick. Some of the "what's" of EJB I learned, I never learned the "why's".
[ February 13, 2004: Message edited by: Keith Rosenfield ]
 
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I go with Keith. It was the same case with me also.. Scoring high on the exam is very easy. By retaining the Tables in memory for one day will help in doing that. But in the long run, only things which we had reasoned out will stay in memory. Still so many questions are unanswered which i may probably get the answer once i start using the concepts in a real time project.
 
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic