Originally posted by jeff mutonho:
It was the client who invoked a business method that resulted in he calling of ejbActivate on the bean.
The point that I tried to make in the fifth post of
Bean Things are confusing!! is that the specification is giving the server the freedom to complete the ejbActivate
before a client invokes a business call in order to serve that
future invocation by a client faster - clearly it would only want to do that for entities that in the (recent) past were in high demand - i.e. it is highly likely that there will be a call coming in for that entity "any time now".
In the ejbActivate you can already perform JNDI lookups which can be "slow/expensive". You can get a hold of your component interface which you will return in place of "this", similarly you can get the home interface.
The peculiar one is getPrimaryKey. This is useless if the object-model was designed first because the data model will usually use synthetic keys only - these keys belong in the category of an
existence based identity - i.e. the key has no further meaning other than uniquely identifying the entity's existence.
In systems where the data model came before the object-model however you can encounter
value based identities - usually a compound key of fields that uniquely identify the entity. These compound keys can include discriminator fields that can be used to configure the entity bean -
even before you run ejbLoad.
So again I state that the specification disallows the access to client specific functions in the ejbActivate so that the server
may complete the ejbActivate even
before a client invokes a business method on that entity bean.
[ October 27, 2005: Message edited by: Peer Reynders ]