• 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

Q Relating to Session Sync Stateful SB

 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a doubt in question hosted on ejbcertificate.com
Here is the question:
Given that a stateful session bean implements the SessionSychronisation interface, select the correct order in which a container calls a transactional business method that throws a system exception.
1 beforeBegin(), business method, afterCompletion().
2 beforeBegin(), afterBegin(), business method, afterCompletion().
3 afterBegin(), business method, beforeCompletion(), afterCompletion().
4 afterBegin(), business method, afterCompletion().

The answer given is 4. And Explanation given is:
If a business method raises a system exception whilst in the context of transaction, afterCompletion() is called on the session bean instance with a boolean value of false to notify the instance that a rollback has occurred.

Now my concern is... Once a System Exception is raised.. the Container will kill the session bean instance.. then how come afterCompleion be called??
 
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
note this in spec page no:79

Notes:
1. The Container must call the afterBegin, beforeCompletion, and afterCompletion methods if the session bean class implements, directly or indirectly, the SessionSynchronization interface. The Container does not call these methods if the session bean class does not implement the SessionSynchronization interface.

so the afterCompletion method is called before bean is toasted i suppose.
 
AmitKumar Jain
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well... even in case of beforeCompletion, container calls it once a transaction commit is requested.

It might be possible in case of system exception, that container calls afterCompletion first and then kills the bean... However it is not mentioned anywhere in the spec.

As far as reading spec is concerned, it is not so scary as you mentioned in your mail. Infact, it gives a cool feeling when you find whatever you read from here and there, is all mentioned in the specification. You can reduce the content if you strictly follow only those sections which are mapped in cheat sheet.
 
AmitKumar Jain
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well... even in case of beforeCompletion, container calls it once a transaction commit is requested.

It might be possible in case of system exception, that container calls afterCompletion first and then kills the bean... However it is not mentioned anywhere in the spec.

As far as reading spec is concerned, it is not so scary as you mentioned in your mail. Infact, it gives a cool feeling when you find whatever you read from here and there, is all mentioned in the specification. You can reduce the content if you strictly follow only those sections which are mapped in cheat sheet.
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Amit,
I think afterCompletion() may work like a 'finally' block in try/catch style. This may help cleaning up resource connections or marking some objects to null either transaction goes through or doesn't.
and it makes sense also if my assumption is correct


Thanks,
Ugender
reply
    Bookmark Topic Watch Topic
  • New Topic