• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

2 stateful bean questions

 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

1) If a stateful bean is in a passivated state & say the client invokes remove will the ejbremove() method be invoked for the same

2) Say if I just have one create no args method in my stateful bean how will the state management work or is it imperative to have a create method with args in case of stateful beans
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by manish ahuja:
Hi

1) If a stateful bean is in a passivated state & say the client invokes remove will the ejbremove() method be invoked for the same


ejbRemove() can only be called by the container on a stateful session bean in the 'method ready' state. The only way a stateful session bean can pass from the 'passivated' state to the 'does not exist' state is if it times-out. I suppose that the way to handle this is vendor-specific, but I suppose that a way for the container could be: when a client invokes remove on a stateful session bean's EJBObject stub, the container will first invoke ejbActivate() on the bean, therefore re-assigning the state persisted during passivation, and then will invoke ejbRemove() on the same.


2) Say if I just have one create no args method in my stateful bean how will the state management work or is it imperative to have a create method with args in case of stateful beans


Why are you interested in constructors? A Stateful session bean must have at least one-no-argument create method, but if a create method with argument exists it's not mandatory (I'm not sure but it should be like that!). The bean's state is saved by the container in a sort of secondary storage, which might mean serialization, or it might not (this is vendor-specific). The only thing the container-vendor must ensure is that something that behaves like serialization will save the stateful session bean during passivation (and therefore will reassign the correct state during activation). Our responsibility as bean-developers is to guarantee that all the instance variables of the stateful session bean will be ready for passivation; in other words these should be a reference to:

1) A Serializable object
2) A primitive datatype
3) A null object
4) A collection or array of Serializable objects or primitive datatypes
5) A JNDI local context
6) A SessionContext
7) A Resource Manager
8) A Remote EJBObject or EJBHome

Hope this will help,

Marco
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marco

Thanks for the response. I think I did not put my 2nd question appropriatley. What i meant about the state management was pertaining to the client state management.
To ellaborate on my question how do we identify the client in case of a no args create method.

I reckon the arguments to create method are basically used for client identification (correct me if i am wrong)

Bye
Manish
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by manish ahuja:
Hi Marco

Thanks for the response. I think I did not put my 2nd question appropriatley. What i meant about the state management was pertaining to the client state management.
To ellaborate on my question how do we identify the client in case of a no args create method.

I reckon the arguments to create method are basically used for client identification (correct me if i am wrong)

Bye
Manish


I don't think so. The argument to the create method have the same meaning as in case of any other Java class. These should be used to initialize the bean's state. If you assign those arguments to instance variables, then yes, the create arguments will correspond to the client's state. But the container will keep track of the client even if the bean will have no arguments. For instance, let's say the client created a Serializable object during the execution of one of the business methods, stored it somewhere and kept a reference to it. The object was created at runtime, not passed as a create argument. If the bean gets passivated and then activated, the client will be assigned exactly that reference to the object. Does this answer to your question?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic