EJB design: Passing EJB reference to other Thread

  1. Passing EJB reference to other Thread (5 messages)


    If I have EJB reference, can I pass it to other thread safely?
    COM had concept of Apartments to handle thread problems and we had to marshal the interfaces if passed to another thread.
    What we do in EJB? Is there any concept like apartments that is hidden?

  2. Unmesh:

       There is no concept as that of appartment in ejb, atleast I havnt came across anysuch thing. secondly it is not advised to store or pass ejb reff. The reason for this is, with container type of behaviour you realy dont know what object refference are you currently connected to (this scenario comes more predominently in picture with stateless sessionbean or message driven bean).

       In case you need to do some asynchronous operations, you can verywell do it through MDB (Message Driven Beans). If you are not using EJB 2 then you have option of JMS(Java Messaging Services.).

    Hope this helps
  3. I was little confused about the thing that in COM literature there it lot of space given to talks about apartments and object identity and passing reference to objects from one apartment to other etc. But in EJB literature generally there is just one line saying 'you should not do it'.
    Why its like that? I am certainly missing some basic undestanding about the purpose of COM and EJB architecture
  4. Hi Chetan,

    Its Ok if I dont know which object I am referring to. As my client is running against 'Transactional interface'. By which I mean each method is running in transaction. I can keep 'state' of the object implementing 'transactional interface' in the resource manager. So each transactional method will modify the state in the resource manager between transaction boundries. Either it will modify the state in case it commits or it will not if it fails. Client cares not about the object it connects to but if the trasactional method in the interface behave properly.
    MTS runtime handles this by 'intercepting' calls to actual MTS objects and transparently creating a new object between each method calls. Client has the remote reference and same reference points to different actual objects on server side.
    Does EJB remote reference work the same way?
    And in this type of scenario, it doesnt matter if you are passing the reference to same object to other thread or creating a new object. I think thats why in case of EJB or any Transactional Middleware it doesnt make difference.
    But COM as it doesnt have any transactional concepts attached cares about it?
  5. Unmesh:

      Frankly speaking I am not at all good in COM, I said bye bye to microsoft some 3 years back, i guess that was the time when COM was really comming in market.

    So my suggestions on COM will be more on commonsense rather than technical proofs.
    What I can tell is, EJBs dont have the situation what u have mentioned in MTS. it does not create multiple objects for a single reff and switch between them on the fly. At the most EJB will have different object reffered by interface but it will be always one object and one refference. That is the reason i guess the appartment threading scenario is not supported in EJBs.

      I will need to dig deep and try to find real good technical reason for the same. Let me know if u find anything on this topic. Letz educate through common problem will be my stand.

    hope u r with me
  6. I said bye bye to microsoft around 2 years back. But programming parsers in java not EJB. Now that I have to learn programming EJB, I had a doubt why COM had so much stress on apartments etc and EJB is not.
    I am with you, will post if I get anything.

    Thanks a lot