Thread in the beans

Discussions

EJB design: Thread in the beans

  1. Thread in the beans (7 messages)

    Hi Experts,

    My question is coming from page 210 of the book. EJB spec doesn't allow multithreaded bean, but the container will provide muiltiple instances of a single-threaded component. So, if all these instances can run concurrently, is it like something of a multithreaded code? is there any difference between them? And how the container can solve the problems of concurrency?

    thanks in advance

    ivan

    Threaded Messages (7)

  2. Thread in the beans[ Go to top ]

    Remember that you yourself are coding the bean implementation class, you're not putting in any synchronisation, and the bean class itself can be compiled in the regular "javac" way. So you can deduce that the bean itself is not multithreaded.

    What the container does is to intercept threads and allocate beans according to their type and the load on the server.
  3. Thread in the beans[ Go to top ]

    Hi Mitchell,

    Thanks for your answer, I think it answered most of my question. I used to write some code with thread in Java. In the main class, I may generate some thread to run those "runnable" objects. When I am writing bean classes, I don't need to consider problem of thread-safe according to spec. My question is, if the container will generate mutiple instance of my bean class, is it the same effect as it generates mutiple threads to run those beans( as in a main class)?
    in this case, how the container be so smart to solve the currency problems ? I am new in EJB, so maybe there are some misunderstanding of concepts.

    Thanks

    ivan
  4. Thread in the beans[ Go to top ]

    If the "effect" is that each client is provided with access in a thread-safe manner, then yes, you could say that it has the same effect.

    It isn't a matter of the container being smart. It just does smoke-and-mirrors tricks to be as easy on itself as possible without violating a client contract. These essence of these tricks is documented in the EJB spec itself (caching/pooling/activation/passivation). I suggest you look there for more info.
  5. Thread in the beans[ Go to top ]

    Thanks Mitchell, I will read the related topic in the spec.

    Ivan
  6. Thread in the beans[ Go to top ]

    I implemented threads in session beans even if the spec does not recommend this. We need it because our remote objects (session beans) have to execute analysis algorithms, which are started from the client and then returning their state. In other words, we can start the algorithm (session bean) in start() method, which immediately returns and then call methods like getState() of this very session been where the algorithm is running within its separate thread.

    It violates the spec but several years ago when we started this project did not find any reason why we cannot do it. Some containers require specific configuration parameters but generally it works fine. The specification does not recommend this practice because of the very general principles and EJB design rules.

    It is my own experience but of course there always exists a danger that it will not work (reliably) on some servers.

    alex

    > Hi Experts,
    >
    > My question is coming from page 210 of the book. EJB spec doesn't allow multithreaded bean, but the container will provide muiltiple instances of a single-threaded component. So, if all these instances can run concurrently, is it like something of a multithreaded code? is there any difference between them? And how the container can solve the problems of concurrency?
    >
    > thanks in advance
    >
    > ivan
  7. Thread in the beans[ Go to top ]

    Threads are generally used by the container to track which transaction your requests are part of. By forking your own threads it makes it impossible for the container to correctly identify which transaction context a call is part of... which may not be a big issue if you're not really performing transactional operations etc..

    Also: the fact that you now have a thread running inside a thing which should have its lifecycle managed by the container means that the container can't effectively manage it's internal resources.

    If you really need to fork off threads inside the ejb container, then you can use MDBs to achieve this (by sending messages and/or having more than one subscriber).

    Another (recommended) solution is to fork off the thread in the client/web tier.

    Nath
  8. Thread in the beans[ Go to top ]

    If you really need to fork off threads inside the ejb container, then you can use MDBs to achieve this (by sending messages and/or having more than one subscriber).


    What is the difference between a direct call of session bean method and calling it via MDB? I mean that in any case the method start an internal thread, which runs even if the method returns. So in any case we have a session bean with no external access registered by container but still active because of this thread.

    > Another (recommended) solution is to fork off the thread in the client/web tier.

    But the problem is that we need to have lengthy operations on the server (say, some complex analysis of user behavior) with the ability to influence this thread while it is running, e.g., by getting its current state, partial results etc.


    alex