• 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

How the second client knows the bean is free?

 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If a second client calls a stateless session bean when this bean is serving the first client, the second client gets an exception. (Head First EJB- page 238- in the third box) Then how the second client knows whether the bean is free? How a fair scheduling is allocated? (Because in practical situation thousands of clients may be waiting for the same stateless session bean & wait(), notify() methods are not normally used in EJB)
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of those cases when I think slightly more careful wording of the situation may make the problem a bit more clear.
No client calls a stateless session bean, at least not directly. They interact with 'the guard' as HFE calls it - invoking methods on the reference to either the EJBObject or the EJBLocalObject, depending on whether you have a remote or local client, respectively.
The exception comes up when two clients try to invoke methods on the same EJBObject/EJBLocalObject at the same time. That can only happen in two circumstances:
1 client gives a refererence to the 2nd client.
1 client spawns a 2nd thread, and both threads try to use the reference.
The distinction is subtle, but important - it just isn't possible for multiple requests to hit the same SLSB instance at the same time. Not only are bean requests serialized by the container, but in the container assigns instances to handle particular method requests on demand - the SLSB instance is not permanently bound to the EJBOBject/EJBLocalObject.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, and the answer to your question of 'how does the second client know?' is "don't do it". Give the second client its own reference to a SLSB via the same home.
 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The situation you described above only relates to a method of the same instance of a stateless session bean being called simultaneously. You can't do thread stuff like wait()and notify() in your bean code. This does not mean that you can't use those methods in your client code. Normally, each client should have its own EJBObject reference to a bean. Each EJBObject will use a different bean instance to execute a method and so you will not have any conflict or exception for the second simultaneous client method call. The only time you would need to worry about two clients calling the same instance of a session bean simultaneously is if they had the same EJBObject or if a single client was running multiple threads simultaneously that were calling methods on the same EJBObject reference. Servlets are a good example of a client that could potentially be thread UN safe. A single servlet instance could be used to process multiple simultaneous requests. You could have a problem if a servlet like this had only one, instance level EJBObject because it could call methods on the same bean instance more than once at the same time. To make a long story short, you need your clients to be thread safe if they are accessing EJBs. Different clients should have different references to EJBObjects that will in turn use different stateless session bean instances from the pool and you will have no conflict with simultaneous requests.
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If a second client calls a stateless session bean when this bean is serving the first client, the second client gets an exception.


I think this claim is false.
Here is from spec on page 101

The container must ensure that only one thread can be executing an instance at any time. If a client
request arrives for an instance while the instance is executing another request, the container may throw
the java.rmi.RemoteException to the second request if the client is a remote client, or the
javax.ejb.EJBException if the client is a local client.[6]

The key word is "MAY". In my opinon, the container can choose to throw exception in such situation. But it is NOT the responsibility of the container to throw exception. I believe most container choose either to serialize the call to the the same bean instance. Or just instantiate a new bean instance to serve the client.
Bean instances are transparent to clients. Since the remote object obtained from home's create method are all conceptually identical. It even doesn't matter you use the same component or not to execute the methods currently.
I would think it is a more consistent for containers to behave the same way when client(s) concurrently invoking SLSB method regardless of how they are invoked because EJB Spec's Stateless Session design emphasize that any two session beans ( I mean the EJBObject) created in the same home are idential.
Am I missing something?
 
Message for you sir! I think it is a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic