Discussions

EJB design: Spawning Threads through Session Bean

  1. Spawning Threads through Session Bean (13 messages)

    Hi Everybody,
    Do anybody knows that is it the right idea from Design point of view to *spawn Threads through Session Bean*?

    And what could be its impact on scalability?

    Thanks
    <Puneet Maini>

    Threaded Messages (13)

  2. Spawning Threads through Session Bean[ Go to top ]

    Threading is not allowed in EJB specifications. So I guess it may not be good idea. Becoz container handeles all these issues.
  3. Spawning Threads through Session Bean[ Go to top ]

    On the other hand take a look at:
    http://e-docs.bea.com/wls/docs61/programming/topics.html#1054342


    There is a bit more in this section but here is quotation:

    "If you decide you must use threads in your application code, your should create a pool of threads so that you can control the number of threads your application creates. Like a JDBC connection pool, you allocate a given number of threads to a pool, and then obtain an available thread from the pool for your runnable class. If all threads in the pool are in use, wait until one is returned. A thread pool can help avoid performance issues and will also allow you to optimize the allocation of threads between WebLogic Server execution threads and your application."
  4. Spawning Threads through Session Bean[ Go to top ]

    Do anybody have any idea about availability of some tested *ThreadPool Manager* class?

    Do weblogic provides some sort of ThreadPool Manager?
  5. Spawning Threads through Session Bean[ Go to top ]

    WebLogic provides you a thread pool directly - you just declare and describe any number of them through Admin Console or in config.xml if you fancy it. Then there's nothing to do, but to use it - lookup by JNDI name and go ahead. Again - spawning threads in an EJB is a BAD thing, they are designed with the purpose of being a single-threaded entities. Maybe you really need it, but I am sure there are other possibilities. By the way, user-created threads in WL 5.x do not get garbage collected - very nice implementation detail...
  6. Spawning Threads through Session Bean[ Go to top ]

    Hi Mr. White
    Thanks a lot for your response.

    User-created threads in WL 5.x do not get garbage collected
    may not impact us, since we are planning to use a pool of Threads which we dont want to be Garbage Collected.

    I did'nt find anything like config.xml in weblogic dir. BTW I'm using Weblogic 5.1

    Do you have any link where I can have some info regarding this?

    Thanks a lot
    --
    Puneet Maini
  7. Spawning Threads through Session Bean[ Go to top ]

    Do you really need a thread pool? I don't know your situation, but in most cases EJBs can fulfill all tasks that required multithreading in an non-J2EE Java project. They are single-threaded entities that perform their work each in their own thread - this IS multithreading, isn't it?
  8. Spawning Threads through Session Bean[ Go to top ]

    You can't portably spawn threads in a session bean. I think the paragraph from WebLogic was reffering to spawning threads in general, not in session beans. I don't think WebLogic supports spawning threads from beans directly.

    The common "sun aprooved" solution is to send JMS messages to a Queue or Topic, and use message beans to concurrently process these messages.
    In some cases this is an overkill. However, there is no portable way to spawn threads directly. If you absolutely must spawn threads directly in your bean, make sure you don't access resources (e.g, DB connections) from the threads. If you do, you are allmost guaranteed to cause a disaster in the transaction manager.

    Gal
  9. Spawning Threads through Session Bean[ Go to top ]

    I am not sure what do you mean by "in general". I have a (toy) stateless session bean that spawns threads just fine.
    This happens within a "business method" (one that is defined in the component interface).
    This method blocks till all threads terminate, so from the containers point of view (unless it peeks)
    the bean is just doing some processing. From what I can see the life cycle of the bean is completely
    normal, i.e it is pooled when the threads terminate and extra bean instance is created if a request arrives
    while the first bean instance is threading.

    As long as I do not touch container resources from my threads and block the caller at the entry point,
    everything should look normal to the container. I agree that these are murky waters though.

    David
  10. Spawning Threads through Session Bean[ Go to top ]

    I keep hearing "It's bad to spawn threads inside a J2EE container" without any follow up explanation. Can some one elaborate what's so evil about it by pointing to specific issues. As long as the threads stay away from resources managed by the container, I don't find anything wrong.

    I have sawned threads on Weblogic startup. The threads called ejb also. The threads were gracefully shutdown on weblogic shutdown. I never experienced any problem.

    Pranab
  11. Spawning Threads through Session Bean[ Go to top ]

    If for example, I have a main application that has a list of Items (ItemA, ItemB, ItemC, ... ItemN). When you click on the Activate button for ItemA, it should execute CheckdbA. What CheckdbA does is that it continouosly retrieves a single record from the database (TableA) and perform some business logic on it. CheckdbA will only stop to execute if you clicked on Deactivate button for ItemA.

    While CheckdbA is executing you should be able to click on Activate button for ItemB to execute CheckdbB. CheckdbA should run independently from CheckdbB.

    My question is do you have to use threads for the main application? So that while CheckdbA is executing, it will not block the main application console (then you can still click on Activate button for ItemB). Or are there any other way to invoke Checkdb asynchronously?

    Just like when you open several instances of Notepad.exe from the Start Menu.

    Another question is, can i write Checkdb as a session bean? That means when I click on Activate button for ItemA, it will instantiate a Checkdb session bean, called CheckdbA. I am asking this question because I would only be needing one client (main application). EJBs are supposed to be server-side components that can serve many clients.

    The client (main application) does not necessarity have to reside on a different machine since, it can be installed on the same machine where the application server is.

    Or would it be better to write Checkdb as an ordinary class file that performs business logic?

    Thanks in advance!




  12. Spawning Threads through Session Bean[ Go to top ]

    Heres what I'm doing in my stateless session bean(S1) business method :

    abc()
    {
       //Call to a private method which would return me an Array
       //of some Data Objects(Length could range from 1 to 4)
       DO[] = xyz();

       for(int i=0; i< ArrayLength; i++)
       {
           //Spawn Threads(Call to a different Session bean - S2
           //method in the Thread class)
       }

       for(int i=0; i< ArrayLength; i++)
       {
           //Wait for Threads which have been spawned to
           //terminate
       }
       return;
    }

    In brief I'm spawing threads in my session bean(S1's) method in a for(;;) loop.
    No of Threads to spawn = Array Length. (Array Length could range from 1 to 4)

    In another for(;;) loop which follow, am waiting for the Threads which I've spawned to terminate.

    So before exiting my session bean method, am terminating all Threads which I created.

    I'm getting quite a lot of Performance improvment by using Threading. Earlier I was calling session bean - S2's method sequentially in the same for(;;) loop.

    And the funda of spawning Threads is working fine.
    I just wanna know if it would work the same way if No of users are increased i.e. under load test.

    Do anybody has experimented with this earlier?

    Thanks to all of you
    --
    Puneet Maini

    P.S : Thing which could look weird in this is each spawned thread is calling another session bean.
  13. Spawning Threads through Session Bean[ Go to top ]

    The code you show could easily cripple your server if it is put under any load.

    Imagine that i=3 (relatively low number) for instance.

    Now imagine you have 10 clients (also a low number).

    Boom, 30 threads potentially running all at the same time. In general much more than 15-20 threads and a JVM doesn't run too well (it will run, but would have been more efficient as two processes with half the number of threads each.)

    Also, the server has _absolutely no idea_ about your threads. This is the critical point. The server will merrily dish out threads of execution to the requestors of those threads until the limit it has been configured for. BUT this limit only governs the threads the server knows about. Now you could be able to get around this with the WebLogic thread pooling classes but I suggest you research this thoroughly in case that's not the case.

    Basically, if your threads come from the client then you're fine. Each execution thread will most definitely be known to the server, since they are all EJB execute threads. Just remember only one thread per bean on the client side.

    That way the server knows about all running threads of execution. For that matter it could load balance them across a cluster for you (something your current implementation can't do.)

    HTH

    Chz

    Tony
  14. Spawning Threads through Session Bean[ Go to top ]

    I have an idea to circumvent this problem.
    We would do something like this.

    Determining the limit of concurrent Threads which our WL server could support easily without breaking down.

    And we would only spawn Thread if we are under this limit, otherwise we would go in a normal sequential way.

    We can do this by having a static int variable like iMaxThreads & would always check the value of this variable before spawning Thread.

    Comments !!!

    Thanx for your help & inputs
    --
    Puneet Maini