• 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

concurrent access of session ejbs

 
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A stateful bean is of one client/ejbObject alone.
A stateless bean its still handling only one client/ejbObject at a time.

"Session beans must NEVER be accessed by more than one client. If two clients access a bean the second client will get an exception.
But the container is free to allow sequential processing for stateless session beans though this is not guaranteed." refer p238 of K&B HFEJB

It appears to me that this exception is simply not possible with stateful ejbs.
With stateless it might happen if the conatiner cannot convert concurrent calls into sequential pocessing by the bean when there is only say 1 bean in the pool and there is no provision to increase the bean size or make new beans.

Or is it this way-

Would a multithreaded client application be considered as one client or multiple clients?
If the component interface type (or stub) is shared by the multiple threads of a client application we might get this exception I guess.

?
 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't see you point !
A multithreaded client call a bean in each thread, then each thread get a different bean instance to run business methods on, no ? Note that statefull bean are kind of pooled as well : this is what happens when the bean is passivated/ativated, the bean instance could return to the pool and service other clients. So why should what you say about stateless beans (pool size, etc..) not apply ?
 
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
With stateless it might happen if the conatiner cannot convert concurrent calls into sequential pocessing by the bean when there is only say 1 bean in the pool and there is no provision to increase the bean size or make new beans

The container must enforce this policy;therefore, I don't think this scenerio will occur.

Suppose client A invokes a method on a stateless session bean. While waiting for the method to complete, client A passes the component interface to client B. Client B invokes a method on the given component interface while client A is still waiting for the method to be complete. Client B will get an exception.

Would a multithreaded client application be considered as one client or multiple clients? If the component interface type (or stub) is shared by the multiple threads of a client application we might get this exception I guess

It will considered to be multiple clients although they may have the same pricipal.

If the component interface type (or stub) is shared by the multiple threads of a client application we might get this exception I guess

Each client will get its own component interface (not sharable), but there is only one home interface.
 
Swamy Nathan
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Suppose client A invokes a method on a stateless session bean. While waiting for the method to complete, client A passes the component interface to client B. Client B invokes a method on the given component interface while client A is still waiting for the method to be complete. Client B will get an exception.



Inside some code say a swing application.
...
...
AComponentInterface aComponentInterface=...
aComponentInterface.method();
...
...

When you say pass aComponentInterface to another client do you mean it gets used by another seperate application? What do you mean by another client? As long as the aComponentInterface is passed to other code running in same JVM and thread would it not be same application?

If clientB is a seperate application in another JVM I dont know how you passed it there.
If clientB is same application in same thread then my understanding is the calls are all processed sequentially and not asynchronously.

So the only option left out it appears is a seperate thread uses same stub and invokes the method.

I am assuming you are wrong about the following
If the component interface type (or stub) is shared by the multiple threads of a client application we might get this exception I guess -
Each client will get its own component interface (not sharable), but there is only one home interface.
(Lets say you share it as a static field why is it not sharable? Unless it is sharable how will you ever get that exception?)

I am assuming you are right about the following
Would a multithreaded client application be considered as one client or multiple clients? If the component interface type (or stub) is shared by the multiple threads of a client application we might get this exception I guess -
It will considered to be multiple clients although they may have the same pricipal.

Another thing-


With stateless it might happen if the conatiner cannot convert concurrent calls into sequential pocessing by the bean when there is only say 1 bean in the pool and there is no provision to increase the bean size or make new beans

The container must enforce this policy;therefore, I don't think this scenerio will occur.



Read page 238n of HFEJB. It says as per the specs the container is free to do this but I suppose that is non-guaranteed behaviour.
[ August 23, 2004: Message edited by: Swamy Nathan ]
 
raphael Bereh
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you need to have a look at RMI Objects and their support for threads !
 
raphael Bereh
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just to elaborate on RMI and Threads .
RMI has support for multi-threading even if the RMI spec. does specify how this is implemented .

The Stubs are RMI/IIOP compatible objects, hence they have to be thread- safe, specially when they do handle state : this is the case with Statefull beans.

I think you are only taking the client side stub into account. But these client side stubs all 'talk' to one ( no ?) stub on the server side !: I think this is where you should be looking for concurrent access, not on the client side ! HF has great picture diagram for the communication (life cycle ) between client / server.

So consider the server side stub being accessed concurrently by multiple threads (this is where you get the Exception, so the scenario is well possible), if the stub is not thread safe, this could result in corruption of state. You know how to fix that kind of issue in J2SE ! But , in EJB ...
Well, no threads, let the container do that for you !

Would be interresting to see the implementation of the ejbObect ( as this is the container's responsibility), this might give us a big clue as to how the container enforces the thread-safety .
 
Joe Nguyen
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So the only option left out it appears is a seperate thread uses same stub and invokes the method.

This is a correct assumption.

Each client will get its own component interface (not sharable), but there is only one home interface. (Lets say you share it as a static field why is it not sharable? Unless it is sharable how will you ever get that exception?)

If you have read the HFEJB this far, you should have known the answer.
 
Swamy Nathan
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You guys need to make your postings clearer.
I am just trying to learn things here.

Let me give you some unconnected advice which you may find useful.
The day you think you are an expert is follwoed by the day you go wrong and start fudging things beacise you cant admit it.
It is important that any person who doles out advice learn to say things like-

You are correct about such and such a point.
You are incorrect about such and such a point.
I was wrong about such and such a thing. I admit it.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic