For SFSBs... Can someone please clarify why EJBs are NOT allowed to be accessed from afterCompletion() method? If ejbCreate() can, why not afterCompletion? My understanding is that 'EJBs or Resource Managers are allowed to be accessed from a method if there is either a client or a transaction or both in the method's scope'. afterCompletion() has client in scope. So it should be allowed to access EJBs. Is my understanding right?
Hi Keerthi, Let me try. As you know, only SFSB with CMT can use afterCompletion. Its executed even if Tx is rollbacked and heance runs without Tx context. If you call other bean from here then you are not sure if there is pre-existing context or not. So if called EJB method needs preexisting context of Tx, there are problems here. This will occour some times as sometimes Tx Commited sometimes its not...so its logically not right to allow ejb's here.
why ejbCreate allows then>??>??? ..
ejbCreate of SFSB runw without Tx context(ok...unspecified one) but when u call other mehtods from here, your sure that there wont be any context pre-existing to the called bean method...hence its allowed over here only to people who dont need or can run without pre Tx context...BP must make sure this point.. Amol.
When I was preparing for the exam I noticed that too. I searched the forum and found out that this subject has been discussed here before (just search by "enterprise bean access" and you will find some discussions. Unfortunately nobody came out with a reasonable explanation about this, as you can see in this thread.
Amol: I'm not sure about your statement. When afterCompletion() runs there is no Tx context at all, no matter whether the previous transaction commited or not. I don't see any difference between this method and ejbCreate() regarding the Tx context. In my opinion, there is an error in the specification because if access to enterprise beans should be allowed in the presence of a transaction or security context, then this access should be granted to the afterCompletion() method since it has a client security context. One could argue that access is allowed only if you have both contexts, but in this case the ejbCrete(), ejbRemove(), etc would violate this rule because they don't have a meaningful transaction context and they still can access another enterprise beans.
PS: I know I didn't come with the solution for this... I'm just trying to warm up the discussion.
Regards, Stefan [ March 21, 2005: Message edited by: Stefan Guilhen ]