• 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

Stateless Session bean pooling? What's that?

 
Ranch Hand
Posts: 428
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anyone explain stateless session beans and pooling? It makes no sense to me!
An explaination in C++ would help because I don't understand JVMs as well as I do C and assembly.
Stateless sessions beans mean clases with no data members, correct? If there are no datamembers (or attributes or state), the only things left are functions. They might as well be static from a purely conceptual perspective since there is nothing for the secret (or implied) argument to point to!
So it sounds to me like like a session bean is conceptually identical to a bunch of static functions or plain old stand-alone non-member functions in C. There is no object! Just functions.
I can call these functions at any time -- I don't need an object. I don't need to call new.
So if was going to implement Stateless session bean pooling for my own EJB implementation, I'd create a linked list of Session beans that were not currently in use. But what would each element of my pool point to? NOTHING! So what is there to pool?
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So it sounds to me like like a session bean is conceptually identical to a bunch of static functions or plain old stand-alone non-member functions in C. There is no object! Just functions.

Not really. Session beans are components that provide business services. The key is, since they are shared components, somehow the container( runtime environment) must be able to service multiple concurrent client requests using fewer object instances. Now, that's another difference, unlike C++ where one runtime process hosts all objects, we are talking about distributed processes here. The concept of container is that it is some kind of an infrastructure that will create and manage the shared distributed service components.

I can call these functions at any time -- I don't need an object. I don't need to call new.

Yes, you don't have to call new, but that's not because of C++ anology. Remember everything in Java( well, everything that has behavior) is an object and you will need to instantiate the object before calling any (non-static) method. The only difference in the EJB scenario is that these objects are created by the container so you( the client) don't have to. You will simply "get to" the container, get the reference to one of the shared objects and invoke a method. Think in terms of other component technologies such as COM/DCOM, if you are aware of them.


So if was going to implement Stateless session bean pooling for my own EJB implementation, I'd create a linked list of Session beans that were not currently in use. But what would each element of my pool point to? NOTHING! So what is there to pool?

The linked list will contain the actual object instances. The container will manage dynamically linking a remote object reference the client has, with one of the free objects in the pool.
 
Siegfried Heintze
Ranch Hand
Posts: 428
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, but what is the difference between an object instance and a static function if there is no state?
If there is no state, why cannot all users use the same instance of the same (non) object? There cannot be any concurency issues if there is no state!
A collegue explained that when the EJB container loads the session beans into a pool, it creates redundant copies of the read only executable code: one for each instance.
Wow! Hard to believe. That is really ugly.
He explained this is necessary for OS vendor neutrality. Ughhh...!
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving topic to "EJB and Other J2EE technologies" forum...
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Yeah, but what is the difference between an object instance and a static function if there is no state?
If there is no state, why cannot all users use the same instance of the same (non) object? There cannot be any concurency issues if there is no state!


Stateless session beans can have state, but they are not client specific. Stateful session beans are server-side client specific objects. But the whole idea is this - by using instance pooling, the container can intelligently manage hundreds of clients with significantly fewer number of bean instances. Because the instances are outside the client tier, smart-stubbing will make the clients think they have their own dedicated server-side object. I cannot think of a way to achieve this using plain-vanilla C++ objects because firstly, there is no concept of client/server demarcation and secondly you will need an infrastructure to support object sharing and pooling.


A collegue explained that when the EJB container loads the session beans into a pool, it creates redundant copies of the read only executable code: one for each instance.
Wow! Hard to believe. That is really ugly.
He explained this is necessary for OS vendor neutrality. Ughhh...!


I am not sure what you mean by read only executable code, but in general the concept of object pooling is not a new thing introduced by EJBs. People have been writing proprietary frameworks to implement instance pooling ever since the concept of n-tier client/server atecture gave birth to shared service-components. EJBs just made the life easier by taking the burden off the shoulders of developers.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic