• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Pretty hard question

 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have a Stateless Session Bean defined and minimum/maximum pool size variables in the container is set to 1. Which of the two is true?
1) The bean instance could be used as a Singleton - each time we request a new bean we will get the same instance.
2) The bean instance can't be used as a Singleton - the EJB spec does not guarantee that the pool will not be cleared and bean instance re-created at some stage.
A question from real life. Just 50% chance to get a write answer. I'll be glad to hear your comments.
/Alex
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer is 2, more over this is entirely dependent on the EJB Implementation since this type of control of the EJB Pool is not guaranteed by the EJB Specification.
 
Andrew Perepelytsya
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suppose, you cannot even guarantee the consistent behaviour when MAX pool size is reached. Some containers may stretch the limit a bit, some (most, I would say) will serialize the access to the beans.
Let's say, what happens if we have MAX set to 2 for SFSB, and there is a third and fourth incoming client connection? Should the container throw the RemoteException? Doubtful.
 
Andrew Perepelytsya
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yet another thought - clustered environment. The idea of Singleton is very very very blurred in this setup. What you can rely on here is a distributed enterpise cache, like XXX (no names, guys ). But this solution is well outta scope of EJB. Interested individuals should look into JCache specification, originally suggested by some big big begemoth company
 
Alex Pisarev
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Perepelytsya:
I suppose, you cannot even guarantee the consistent behaviour when MAX pool size is reached. Some containers may stretch the limit a bit, some (most, I would say) will serialize the access to the beans.
Let's say, what happens if we have MAX set to 2 for SFSB, and there is a third and fourth incoming client connection? Should the container throw the RemoteException? Doubtful.

I think for SLSB each client will get the same copy of bean simultaneously.
 
Andrew Perepelytsya
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I think for SLSB each client will get the same copy of bean simultaneously.

If it is like that, then one of the most important EJB guarantees is violated - thread-safety. SLSB can have state, but only pertaining to all clients. If 2 clients get the same instance, you cannot ensure thread-safety without synchronisation, hence you break the rules.
 
Kalpesh Soni
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think...
If cache size is 2 for SFSB and two clients are already inside a bean method
third guy will have to wait
 
Kalpesh Soni
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ok look at this (from "Mastering ejb 2nd edition" )
changed the client slightly
the hashcode says that, when a bean is activated, it actually uses a NEW object ?!

output
========
see carefully
a new line whenever a new bean object is found !!!
examples.CountBean_12vkrz_Impl@ff351667 setSessionContext() weblogic.ejb20.internal.SessionEJBContextImpl@ff35168b
examples.CountBean_12vkrz_Impl@ff351667 ejbCreate() 0
examples.CountBean_12vkrz_Impl@ff351667 count() 1
examples.CountBean_12vkrz_Impl@ff1692c6 setSessionContext() weblogic.ejb20.internal.SessionEJBContextImpl@ff1692d8
examples.CountBean_12vkrz_Impl@ff1692c6 ejbCreate() 1
examples.CountBean_12vkrz_Impl@ff1692c6 count() 2
examples.CountBean_12vkrz_Impl@ff16ca04 setSessionContext() weblogic.ejb20.internal.SessionEJBContextImpl@ff16ca0b
examples.CountBean_12vkrz_Impl@ff16ca04 ejbCreate() 2
examples.CountBean_12vkrz_Impl@ff351667 ejbPassivate() 1
examples.CountBean_12vkrz_Impl@ff16ca04 count() 3
examples.CountBean_12vkrz_Impl@ff1692c6 ejbPassivate() 2
examples.CountBean_12vkrz_Impl@ff173004 ejbActivate() 1
examples.CountBean_12vkrz_Impl@ff173004 count() 2
examples.CountBean_12vkrz_Impl@ff16ca04 ejbPassivate() 3
examples.CountBean_12vkrz_Impl@ff173a6c ejbActivate() 2
examples.CountBean_12vkrz_Impl@ff173a6c count() 3
examples.CountBean_12vkrz_Impl@ff173004 ejbPassivate() 2
examples.CountBean_12vkrz_Impl@ff172aca ejbActivate() 3
examples.CountBean_12vkrz_Impl@ff172aca count() 4
examples.CountBean_12vkrz_Impl@ff173a6c ejbPassivate() 3
examples.CountBean_12vkrz_Impl@ff1712a7 ejbActivate() 2
examples.CountBean_12vkrz_Impl@ff1712a7 ejbRemove() 2
examples.CountBean_12vkrz_Impl@ff170209 ejbActivate() 3
examples.CountBean_12vkrz_Impl@ff170209 ejbRemove() 3
examples.CountBean_12vkrz_Impl@ff172aca ejbRemove() 4
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic