• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DI doubt in Session Bean

 
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys,

The following lines are from the EJB 3.0 in Action book,



What do we mean here by JNDI?? It is almost the same isn't it?
 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jothi,

JNDI is not really the same. You can use it to obtain a reference to some dependencies or resources but it works just the other way round than dependency injection. You actively look up the things you want in the case of JNDI and with DI the container (or another framework) injects it. That's why it's a principle of IoC (= inversion of control).

I'm not 100% sure why it's not allowed to inject a stateful component into a stateless but I guess with injection it would be injected into a member variable which would then be shared by multiple threads accessing the same stateless bean object. This would in turn make it unpredictable which thread would see which injected resources. The container simply couldn't handle that every client sees the correct injected resources in this scenario. If you use JNDI to look up a stateful component and save it into a local variable within a method no concurrency conflicts can happen because local variable are thread-safe per definition. That's just a guess, but it makes sense, I think.

Marco
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason why you must not inject a SFSB in a SLSB is simple. Since you have injected an SFSB into SLSB, you are expecting the state to be maintained in the SLSB, which is not what the SLSB contract mandates.

Consider SLSB-A and SFSB-B. A client gets hold of an instance of SLSB-A (let's call it SLSB-A(1)). When the injection happens in SLSB-A(1) an instance of SFSB-B(1) gets injected into it. Client does some operation on SLSB-A(1) which internally sets some state on the SFSB-B(1). The control then returns back to the client. Now the client does some other operation on SLSB-A. Remember that since SLSBs are pooled and as per the contract are not guaranteed to store state across calls, the container can forward the call to a different instance of the SLSB. So the second call might go to SLSB-A(2) which means that the state stored in SLSB-A(1) isn't available to SLSB-A(2).
 
Ranch Hand
Posts: 608
Eclipse IDE Spring Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But doesn't this:

1. Keep in mind that you must not inject a stateful session bean into a stateless
2. object, such as a stateless session bean or servlet that may be shared by multiple
3. concurrent clients (you should use JNDI in such cases instead).



hold true ,just because with JNDI you could lookup the stateful bean and assign it a a local variable to store in the HTTPSession later.Whereas DI doesn't allow injection into local variables?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic