In HFE book, in page 354, it says that during ejbActivate(), one cannot "get the security info of the client, cannot force a transaction roolback, find out if the transaction is already rolled back, access another bean's method or access a resource manager..". All of this is possible in ejbLoad()
One can understand that in ejbPassivate the bean is no longer associated with a client or a transaction hence these methods are not feasable..Would like to understand why this restriction is in place for ejbActivate..
ejbActivate would have been called when a client calls a business method which in turn makes the container to get the bean for the entity from the pool and then call the ejbActivate.. In such a case would not this method have access to the client security info ?
In this state transition, the bean has already associated a valid primary key, but the underlying entity is not yet synchronized, menas that the rest of your data fields are invalid. Therefore, it does not make sense to change or read them. No transaction is needed therefore. And under this circumstances, what would you like make with the security info?
I think it would be better to get the client security info to verify whether the client has permission to access the bean method. In this way, the container does not need to load data when the client does not have permission accessing the method (it's kind of lazy initialization)
You have two possibilities: - declarative security: it's the job of the container - procrammatic security: it's the job of the bean provider
In this case, the programmer checks if the caller is in a specific role. How would you implement "each client has access to the data of its own account"? You can't make this delcarative. And you can't make this if the data is not yet loaded. Yo need the account number to check if it is the account of the caller. Therefore, a check in ejbActivate is not possible, since the data of the bean is not yet available.
But perhaps you have an example that shows the contrary...?