• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Q Relating to Session Sync Stateful SB

 
AmitKumar Jain
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • 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??
 
cheenu Dev
Ranch Hand
Posts: 276
  • Mark post as helpful
  • send pies
  • 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
  • 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
  • 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.
 
Ugender Rekulampally
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • 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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic