If the client request is associated with a transaction T1, and the instance is not associated with a transaction, the container suspends the client�s transaction association and invokes the method with an unspecified transaction context. The container resumes the client�s transaction association (T1) when the method (together with any associated interceptor methods) completes. This case can never happen for a message-driven bean or for the invocation of a web service endpoint method of a stateless session bean.
Message driven beans can have Transaction attribute specified as Not Supported or Required. In the case of Not Supported - the above can happen?. Also, why is not applicable for invocation of a web service endpoint method of a stateless session bean and applicable for a stateless session bean call?
Yes, MDB and Web Service End point session bean this cannot be happen for both of them.
In case of MDB, the message arrives at container and it invokes the onMessage method, so there is no caller and hence there is not a transaction.
In case of WebService Endpoint, currently there is no way to propogate the caller's initiated transaction to your EJB. Caller can be .NET client or in anyother language, so there is no mechanism to propogate that caller's initiated transaction to WebService End point.
If Client is associated with Transaction - T1 and invokes the MDB having transaction attribute Not Supported.
Client cannot call the MDB directly because client will simply generate the message for some specific Queue or Topic in the container and it is not required that MDB should be up at that time, MDB can be down. If destination is Queue or Durable Topic then after the MDB will be up, it will get the message.
So container calls the onMessage method of MDB, so there is no client associated with it and hence no transaction context. That is why MDB supports only two transaction attributes NotSupported or Required. If MDB's attribute is NotSupported then it will run in un specified transaction context and if transaction attribute is Required then a new transaction will be started by container.
I think the spec is correct also because MDB is asynchronous. The calling method won't suspend to wait for MDB to complete. The calling method will continue executing after it sends the message to the JMS destination. So, the suspension of the calling tx does not apply to MDB.