Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt in reentrancy

 
Sajid Moinuddin
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bean A(entity with id 10) calls a method of bean B(entity with id 20)...Bean B looks up bean C(stateless session) and calls a method on it. Bean C calls bean A(entity with id 10)... now is this reentrant??
Mind it that Bean a doesn't pass it's component interface to bean B.
In jboss it runs well without reentrancy ...But is that legal?
regards,
Sajid
 
Nishant Verma
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sajid

I will like to ask some questions:

1. How did you make sure that Bean A is being accessed concurrently, due to loopback from bean C?
2. How is container controlling the concurrency?
*** Is this a read-only concurrent access ***


[ June 22, 2006: Message edited by: Nishant Verma ]
 
Sajid Moinuddin
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know the bean is not accessed concurrently. But the container is not supposed to be intelligent enough to know that...if it finds calls to the same bean reentranly within the same transaction, concurrent or not, it should throw exception.
 
Nishant Verma
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sajid
Your post is very little on details. Please dont mind me. I am trying to help.

Two important aspects you should post :

1. Business method which you think is concurrent. Pls paste the code.
2. Deployment descriptor of the participants [ the transaction-type / trans-attribute of methods etc]

Now re-entrant = False, means that bean will throw an exception when you invoke *same* method in the *same* bean instance in the *same* transaction context. Are you able to configure this scenario?

Same tx context is a must condition to obtain this scenario. This situation is different when you have two different clients accessing the bean simultaneously in different tx context [RequiresNew]. This should be legal. But since container cannot distinguish legal from illegal. It will block both and in this case this as well.

Again pls refer to 10.5.11 EJB 2.0 specs for legal loopback Vs ill-legal concurrent calls.

Thanks
Nishant
 
Nishant Verma
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sajid
Since I am not a bulletproof expert, would you please consult the top-guns in this post?
http://www.coderanch.com/t/160657/java-EJB-SCBCD/certification/reentrant

Take concurrency with a pinch of salt : Its not a disadvantage everytime. For the purpose of exam you can call this a vice, since EJB specificatons prohibits making Entity beans re-entrant. However having concurrency is extremely vital for high transactional systems. Serialized access to an Entity Bean can cause deadlocks and hanging clients.

Hope that helps.

Cheers
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic