Discussions

EJB design: Can a Handle in a bean to another bean "survive" passivation?

  1. I have one bean instantiating another bean and saving a Handle to the second bean in the class variable (Handle is Serializable). After both beans are passivated and the first one comes back, I get an rmi exception when the field where the bean is supposed to have a handle is being populated. Is it a correct behaviore?

    [bean2] bean2.setSessionContext()
    [bean1] TRANSACTION ROLLBACK EXCEPTION:Assigning instance of class bean2$Proxy to field bean1#hand; nested exception is:
    java.rmi.NoSuchObjectException: Assigning instance of class bean2$Proxy to field bean1#hand
    [Translated] java.rmi.NoSuchObjectException: Assigning instance of class bean2$Proxy to field bean1#hand
    [

    Thanks,
    Alex
  2. Why are you using a Handle? The EJB 1.1 spec requires containers to be able to passivate Home and Remote interfaces as instance members EVEN if they are not serializable.

    Dave Wolf
    Internet Applications Division
    Sybase
  3. If a beanA is using a beanB and both are passivated, I want when they are activated again for beanA to still have a valid reference to beanB (Handle, remote interface anything...), so two statufull beans can maintain conversational model. BTW, I use JBoss.
  4. Why are you using a Handle? The EJB 1.1 spec requires >containers to be able to passivate Home and Remote >interfaces as instance members EVEN if >they are not serializable

    This only applies to Session Bean only, not valid for
    entity bean.
    handle can survive passivation but it cannot survive
    server crash..more reliable way is to use the primary
    key.
  5. You should release the handle on the other bean in the ejbPassivate method.

    You should reacquire it during ejbActivate.

    That definitely works.

    If you are using the Handle then you are getting a little close to the inner workings of the server. The closer you get to that, the less the spec has to say, the more freedom the vendor has to do what they like.

    Do what the others say here, use the stuff further from the core, like the interfaces.

    That would be my view in any case.

    Chz

    Tony
  6. How would I be able then to continue a conversation from one statful bean with another statful bean after they both have gone through passivation/activation. I want both beans to remember were they left after they are activated. Let's say I do not use handles, but after activation I want beanA to refer to the same beanB(as it maintains state), that beanA created and used before being passivated, doable?
    Alex
  7. During passivate, extract the information from the bean that you will need to re-look it up from the home interface and store that in a field that will be passivated.

    When you are activated, take that value(s) and use it to re-look up the stateful session bean from the beans home interface.

    You shouldn't rely on getting the exact same bean back. Remember that inbetween passivation and activation the other bean could have gone away due to a server crash on another server. In that case you would have to re-look it up in any case. Stateful session beans do not survive server crashes.

    As long as you have the information from the bean that you need to look it up again you'll be fine.

    ejbPassivate is called before passivation, ejbActivate immediately after activation, so you should have everything else you need.

    Anyone else think of another way? I'd be interested to hear them.

    Chz

    Tony
  8. How would I be able then to continue a conversation from >one statful bean with another statful bean after they both >have gone through passivation/activation.


    For you case nothing you need to do really, these references will survive passivation/activation,this
    is taken care by the container.
  9. That's what I thought. But in JBoss I get an RMI exception during activation:
    [BeanA] TRANSACTION ROLLBACK EXCEPTION:Assigning instance of class $Proxy13
     to field BeanA#hand; nested exception is:
            java.rmi.NoSuchObjectException: Assigning instance of class $Proxy13 to
    field BeanA#hand
  10. JBoss is not following the spec then, in other words, it is
    a bug.