Discussions

News: Mastering EJB 3rd Ed. Chapters - EJB Best Practices, EJB Timers

  1. Two new chapters, from the Mastering EJB (3rd Edition) book-in-review, are available for download. The EJB Best Practices chapter provides guidelines for designing, developing, building, testing and working with EJB. The EJB Timers chapter provides a complete overview of the EJB timer service and looks at some of its shortcomings in the current spec.

    Download and Review EJB Best Practices and EJB Timers

    Threaded Messages (12)

  2. Double take[ Go to top ]

    Is it just me, or did anybody else look at the title of this news item and think somebody is writing about best practices for EJB 3:

    "Mastering EJB 3 Review Chapters - EJB Best Practices, EJB Timers"

    Ryan
  3. Double take[ Go to top ]

    Yep I thought the same thing
  4. Double take[ Go to top ]

    Is it just me, or did anybody else look at the title of this news item and think somebody is writing about best practices for EJB 3:"Mastering EJB 3 Review Chapters - EJB Best Practices, EJB Timers"Ryan
    That kind of marketing you have to do when selling 3rd edition of the same book. ;-)
  5. Double take[ Go to top ]

    Ryan,

    You're right, the title was misleading. It's been fixed.

    Thanks,
    Nitin
  6. Singleton EJB[ Go to top ]

    Singleton EJB - Why should some one want to make a Singleton EJB that even by restricting the max. bean size to 1? Can anyone pls explain me of its use???
  7. SingleTon Ejb[ Go to top ]

    Hi,

    Regarding your query about singleton EJB , I will clarify to the best of my Knowledge.

    Actually when a client's request is submitted to the middle tier, we normally pass the request to a servlet.This servlet may be the controller servlet.If more than one client submits their request, a new thread will be created for each request.Some people wants to avoid this and they introduce a singleton servlet which simply receives the request from a client and forward it to the controller.The singleton servlet does no other jobs.

    Alternatively if we use a singleton stateful session bean as a substitute for this singleton servlet, we can achieve the same result.As singlethreaded servlet has been removed from servlet 2.4, we have to use a singleton Session bean for achieving this with its limitation.

    Hope this clarifies. Any other comments,Alternatives???
  8. SingleTon Ejb[ Go to top ]

    Actually when a client's request is submitted to the middle tier, we normally pass the request to a servlet.This servlet may be the controller servlet.If more than one client submits their request, a new thread will be created for each request.Some people wants to avoid this and they introduce a singleton servlet which simply receives the request from a client and forward it to the controller.The singleton servlet does no other jobs.
    This is not correct. A thread pool is used by almost every modern application server, so threads are [basically] never created to service requests. As TCP/IP connections come in (for HTTP requests) those connections are handed off to threads in the pool to be serviced. Those threads are either going to go to a Servlet, which is typically exactly one instance of the specific Servlet implementation class that the application provides. If the Servlet implements the marker interface for single thread access (called SingleThreadModel) then the app server will instantiate one instance of that Servlet class for every concurrent thread that is calling into that Servlet; typically these Servlet instances are pooled, just like threads are.
    Alternatively if we use a singleton stateful session bean as a substitute for this singleton servlet, we can achieve the same result.
    Since there is no "result" with the Servlet, I am not sure what would be accomplished with an EJB. What exactly is the goal?
    As singlethreaded servlet has been removed from servlet 2.4, we have to use a singleton Session bean for achieving this with its limitation.
    It (SingleThreadModel) has been deprecated, but I'm going to guess that it still works as it always has. It's called "inertia" ;-) .. app server vendors don't bother going back to rip stuff out that is already there and working.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  9. SingleTon Ejb[ Go to top ]

    I think cameron purdy had not clearly understood what i meant.

    Even if the threads are obtained from the thread pool, say if the pool consists of 50 threads if 50 clients submits request 50 threads will be created simultaneously without any control.The idea of having a single thread servlet in front of this is to pass the incoming request one at a time, so that we can have a some restriction on using the controller thread.The passing will happen in a fraction which is irreleavent. The advantage we have is all the requests are routed with this single threaded servlet instead of 50 parallel routes.

    This practice probably referred to Front controller pattern is in practice quite from 1970's even on cics and other mainframe systems. J2ee Architecture also follows the same. Refere to websphere's site archievs for further clarifications.

    Its true that we can not submit form requests to EJb controllers.Can any one suggest other alternatives instead of having singlethread servlets for this?(as single threaded model is deprecated in servlet 2.4)

    Do not suggest me to use synchronised method as it doesn't avert the creation of parallel threads.

    Anticipating new ideas ???
  10. SingleTon Ejb[ Go to top ]

    Please read "50 threads will be created simultaneously " as 50 threads will be obtained from the thread pool simultaneously. Sorry for the typo graphical error.
  11. SingleTon Ejb[ Go to top ]

    Even if the threads are obtained from the thread pool, say if the pool consists of 50 threads if 50 clients submits request 50 threads will be created simultaneously without any control.
    I don't know what you mean. When 50 requests come in simultaneously, they will be farmed out to 50 threads in the pool. I'm not sure what you mean by control.
    The idea of having a single thread servlet in front of this is to pass the incoming request one at a time, so that we can have a some restriction on using the controller thread.
    There is no such thing as a controller thread. Marking a servlet as single thread model does not change the following statement that I made:

    When 50 requests come in simultaneously, they will be farmed out to 50 threads in the pool.

    In other words, if 50 requests come in and your from servlet is a single thread model, then the container will send those requests to 50 threads, and those threads will each send the request to a different instance of that servlet (that's how most containers that I've worked with are implemented.) Here's the doc from the Servlet API:
    public abstract interface SingleThreadModel

    Ensures that servlets handle only one request at a time. This interface has no methods.

    If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.

    This interface does not prevent synchronization problems that result from servlets accessing shared resources such as static class variables or classes outside the scope of the servlet.
    The advantage we have is all the requests are routed with this single threaded servlet instead of 50 parallel routes.
    I do not believe this to be correct in any way. However, there may be containers which do operate as you indicate, since that would be legal within the spec (to synchronize on the servlet while running the requests) but if it does that for the front servlet, that would basically make the entire container into a single-threaded engine, which would be pointless.
    This practice probably referred to Front controller pattern is in practice quite from 1970's even on cics and other mainframe systems. J2ee Architecture also follows the same. Refere to websphere's site archievs for further clarifications.
    I understand the front controller pattern for HTTP applications; I've used it quite a bit. It is _not_ about threading -- it's about having the first and last shot at every request. (These days you can accomplish the same with a filter.)
    Do not suggest me to use synchronised method as it doesn't avert the creation of parallel threads.
    I am not trying to suggest anything, because I am not certain yet what you are attempting to accomplish with the "singleton servlet" or "singleton ejb" .. if you can explain what the goals are for it, I _might_ have a suggestion if I have seen the same issues before.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  12. SingleTon Ejb[ Go to top ]

    Cameron Purdy,

    Don't take it anything personal.I mentioned Do not suggest in the sense that it is not for you.

    I describe the situation.

    I am following the Mvc Pattern in a web based application. I have one controller servlet which is not single threaded. This servlet acts as a controller part directing the incoming requests to the appropriate business
    classes. Infront of this servlet I am having a singleton servlet which receives one request at a time and forward the request to this controller servlet.

    Can u sujjest me the right thing now?

    cheers
  13. "singleton" servlet?[ Go to top ]

    Don't take it anything personal.
    Don't worry about that at all .. I am just trying to understand what you were suggesting.
    I am following the Mvc Pattern in a web based application. I have one controller servlet which is not single threaded. This servlet acts as a controller part directing the incoming requests to the appropriate business
    classes. Infront of this servlet I am having a singleton servlet which receives one request at a time and forward the request to this controller servlet.
    How do you know that it is single threaded in the app server? I've never seen anything that works at all like this. Out of curiousity, have you taken a thread dump during a load test to verify that it actually works like you think it does?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!