This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

concurrency + stateless session beans  RSS feed

 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a question regarding concurrency in a stateless session bean:

EJB, by default, prohibits concurrent access to bean instances.

I am assuming then that an instance of an object created by a session bean is also concurrent (provided the only access to it is via method calls on the EJB).

The reason I ask is that I have an application object that I want to store in an instance of an EJB. I don�t want multiple hits on this instance while one thread is running (it�s making a connection to a mainframe). So if I define the object as an instance variable of the stateless session bean, does concurrency still hold?

thank you
Max
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,


The reason I ask is that I have an application object that I want to store in an instance of an EJB. I don’t want multiple hits on this instance while one thread is running (it’s making a connection to a mainframe). So if I define the object as an instance variable of the stateless session bean, does concurrency still hold?

Yes this is actually the meaning of thread save. Every client will talk to a different bean instance and therefore clients will never share bean’s instance variables. Hence you don’t need to worry, about providing a thread safe object nor to synchronize the access to your object.
Regards.
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,

Although a session bean will not be accessed by two or more threads concurrently, it is possible that concurrency issues still creeps in. Lets say we've a stateless session bean that calls an API to update a row in the database. We can have many different clients invoking this feature at the same time. Hence, at that time, we may have two or more instances of the stateless session beans servicing different clients.

And if each client is requesting to update a same row in the database, we're going to have concurrency issues. The container only assure us that at any point of time, only 1 thread can be accessing an instance of a session bean. This doesn't really close out all possibilities of concurrency issues.

Hope I'm being clear.
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lee,

You are right about this type of concurrency issue and this is why databases have transaction isolation levels. However this might happen when two different clients access an external global service through different bean instances, such as databases, jms destinations, ldap, etc. Max original question was about concurrent accessing local bean�s instance attributes, which is a completely different kind of story.
Regards.
 
Max Tomlinson
Ranch Hand
Posts: 365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the replies - I understand the problems with DB concurrency but fortunately that's not the problem I'm trying to address - your replies confirm what I read in Monson-Haefel - I just wanted to make sure.
thanks again,
Max

[ April 19, 2005: Message edited by: Max Tomlinson ]
[ April 19, 2005: Message edited by: Max Tomlinson ]
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Valentin,

I understand its a different story between the two. Was trying to point out that concurrency issues are not entirely eliminated although each bean instance is thread-safe.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!