Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

operations allowed in the methods of Stateful session bean

 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reference: EJB 2.0 Final Reference Spec
Page: 80

This question is regarding operations allowed in the methods of Stateful session bean
Why is that "resource manager access" and "enterprise bean access" not allowed in afterCompletion method?
 
Sany Bel
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had the same doubt and I've already posted this question.
http://www.coderanch.com/t/159090/java-EJB-SCBCD/certification/afterCompletion-method
 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sany I read the thread that you gave and you know what I am more confused..

Does ejbCreate() have a transaction context?


To my understanding "NO" (please correct me if it is wrong). In the thread Mr. Crettaz says that Thsi means that if any of those conditions (not both of them) is not true, then the access is disallowed.
, if this is the case ejbCreate() should not have access to "resource managers & enterprise bean access".

Sany-->
Did you get an answer to your question regarding this issue? If Yes can you please give the answer..?
Thanks,
Santosh

Thanks,
Santosh
 
Sany Bel
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you see my last response, I mentioned that ejbCreate() does not have a meaningful transaction context nad still has access to resources managers and other beans. So, to answer your question about ejbCreate(), it does not have a meaningful transaction context. To answer your other question, I am still waiting for my question to be answered.
 
Baskaran Vengesanam
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The reason because SFSB's ejbCreate(), ejbRemove(), ejbActivate(), ejbPassivate() methods run in "unspecified transaction context", not in "meaningful transaction context". But it still has "security context" which allows the bean to have access to another EJB or resource manager.
Hope, this answers your question.
 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So Baskaran according to what you said afterCompletion() method does not have security context ?
What methods in SFSB have Security Context ? Is there a mention of this in EJB2.0 Spec??
Thanks,
Santosh
 
Weerawit Maneepongsawat
Ranch Hand
Posts: 203
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Santosh Ram:
So Baskaran according to what you said afterCompletion() method does not have security context ?
What methods in SFSB have Security Context ? Is there a mention of this in EJB2.0 Spec??
Thanks,
Santosh


I'm not sure,
All of these have Clinet Security Context
ejbCreate()
ejbRemote()
ejbPassivate()
ejbActivate()
afterBegin()
beforeCompletion()
but not these
setSessionContext()
afterCompletion()
Fix me,.
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does my cheat sheet about bean life cycle help?
 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Valentin Crettaz,
The cheat sheet is more like memorizing the stuff the that can be done. I did not get the answer for the following
Reference: EJB 2.0 Final Release
Page: 80/81
ejbRemove() and afterComplete() methods do not operate under a transaction context.
on Page 81: Invoking the getCallerPrincipal and isCallerInRole methods is disallowed in session bean methods for which the container does not have a client security context

both ejbRemove() and afterComplete() methods can access getCallerPrincipal and isCallerInRole which means that both are in Client Security COntext (is it not?). If afterComplete() is in CLient Security Context it should be able to access resource managers and enterprise beans but the spec says that (on page 80) afterComplete() can't access resource managers and enterprise beans.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Several session bean methods - newInstance, setSessionContext, ejbCreate, ejbRemove, ejbPassivate, ejbActivate and afterCompletion - are called with an unspecified transaction context. As the EJB specification does not prescribe how the Container should manage the execution of a method
with an unspecified transaction context, the bean provider is compelled to write these methods in a conservative way. The reason is that the bean provider has no way of knowing what the Container will do, so conservative coding prevents possible problems such as the resource managers accessed from the method being left in an unpredictable state should there be a failure in the method.
 
cyril vidal
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
If afterComplete() is in CLient Security Context it should be able to access resource managers and enterprise beans but the spec says that (on page 80) afterComplete() can't access resource managers and enterprise beans.

Where is it said that client security context involves automatically Resource manager Access and Enterprise bean access??
I didn't read this anywhere in the spec...
1�) You may have security context and although don't be allowed to acess resource managers and enterprise beans (this is the above example for afterCompletion stateful CMT method
2�) you may not have security context and be although allowed to acess resource managers and enterprise beans: please refer to onMessage method of Message driven beans spec p.320
So, I would rather say that client security context and resource manager access and Enterprise bean access are independant, although they may appear both
Regards,
Cyril.
[ April 13, 2004: Message edited by: cyril vidal ]
 
Vipin Mohan
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question is simple.
The afterCompletion method - has a client security context and unspecified transaction context. It cannot access resource managers and other beans
The ejbCreate, ejbPassivate etc. methods - also have a client security context and unspecified transaction context. However they can access resource managers and other beans.
Why this difference ? Surely someone should be able to explain why.
Please help. Thanks in advance.
-Vipin
 
Victor Larr
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If client x calls method1() and method2() of SFSB y in a transaction then container will call afterBegin(),method1(),method2(),beforeCompletion(),afterCompletion(boolean), assuming method1() and method2() have transaction attribute set to "Required". What kind of code Bean Provider would put in afterBegin(),beforeCompletion(),afterCompletion(boolean)? Bean Provider can update bean state with latest data from a database in afterBegin(), modify it in method1() and method2(), write it back into database just before transaction completes in beforeCompletion(). In afterCompletion(false) Bean Provider can undo the changes to bean state because transaction was rollbacked. In this scenario it does not make sense to access database in afterCompletion. I think writers of the EJB specs had this scenario in their mind when they decided not to let programmers access database and other ejb in afterCompletion. Someone can probably come with a reason that they need to access the database in afterCompletion() but the code can be refactored and made cleaner without doing so.
 
sean mullins
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So then is it fair to say that afterCompletion() is some kind of special state, with unspecified transaction context and some sort of "partial" client security context (as it can access getCallerPrinciple and isCallerInRole),
but can't access things like resource managers and other enterprise beans that should be accessible in a "normal" client security context?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic