arch-itect
asked on
await+signal (wait+notify) servlet threads
Hi
Could/should I use EJB in this scenario?
I have a servlet that implements the answer to this solution (sweets packet answer):
https://www.experts-exchange.com/questions/24924094/replacing-synchronized-wait-notify-methods-with-the-ReentrantLock-class.html
When I apply the above solution to my servlet I get an IllegalMonitorStateExcepti on, although I have an JSE version which works.
I am managing the threads myself in the servlet without the use of EJB.
To use the above metaphor, the sweets packet (persistent object) is instantiated, then children (client side) would grab sweets over http (entering on servlet thread_1) and the parent would replenish sweets from the database (server side working in daemon thread_2).
In real life a screen extending the Screen class is instantiated in a servlet (running in thread_1). The client might make a request like "purchase" to the server. The purchase method of the screen object is invoked on a second thread (thread_2). That purchase method might require client input, so it could pause itself and resume the servlet thread to prompt for client input. When the client input arrives, the servlet thread would pause, waiting for further instructions from the purchase method etc.
Question :
Can I run a statefull session bean (SFSB) in a new thread and pause its execution while an http request completes as below?
An http conversation might look like this:
Could/should I use EJB in this scenario?
I have a servlet that implements the answer to this solution (sweets packet answer):
https://www.experts-exchange.com/questions/24924094/replacing-synchronized-wait-notify-methods-with-the-ReentrantLock-class.html
When I apply the above solution to my servlet I get an IllegalMonitorStateExcepti
I am managing the threads myself in the servlet without the use of EJB.
To use the above metaphor, the sweets packet (persistent object) is instantiated, then children (client side) would grab sweets over http (entering on servlet thread_1) and the parent would replenish sweets from the database (server side working in daemon thread_2).
In real life a screen extending the Screen class is instantiated in a servlet (running in thread_1). The client might make a request like "purchase" to the server. The purchase method of the screen object is invoked on a second thread (thread_2). That purchase method might require client input, so it could pause itself and resume the servlet thread to prompt for client input. When the client input arrives, the servlet thread would pause, waiting for further instructions from the purchase method etc.
Question :
Can I run a statefull session bean (SFSB) in a new thread and pause its execution while an http request completes as below?
An http conversation might look like this:
[http post request] client clicks : "purchase"
[thread_1] servlet invokes purchase method in thread_2 and pauses itself]
[thread_2] purchase method starts, hits database etc. needs client input, pauses itself, resumes thread1
[http post response] servlet message "how many"
[http post request] client enters : "5"
[http post response] servlet message "here is 5 for you"
[thread_1] servlet resumes thread_2 and thread_1 dies
[thread_2] completes and dies
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
- how does one manage multithreading in a servlet ?
Servlet or not - threads are managed in the same way anywhere. EJBs are exceptions since they are managed by container. Basically you spawn a thread, let it run and probably poll it periodically, checking for some condition. When the condition is met, the parent thread continues, the child thread dies.
- Multithreaded applications are still possible, but control of multithreading is located in the container, not in the enterprise bean.
That's related to my previous comment. If you need to organise a co-operative process involving more than one thread, EJBs are not for you where it comes to organising the process. All manipulations with threads have to be done outside of EJBs. However, you can spawn a thread, it can instantiate an EJB, call its methods and consume the results, but no manipulations with threads inside EJBs.
Servlet or not - threads are managed in the same way anywhere. EJBs are exceptions since they are managed by container. Basically you spawn a thread, let it run and probably poll it periodically, checking for some condition. When the condition is met, the parent thread continues, the child thread dies.
- Multithreaded applications are still possible, but control of multithreading is located in the container, not in the enterprise bean.
That's related to my previous comment. If you need to organise a co-operative process involving more than one thread, EJBs are not for you where it comes to organising the process. All manipulations with threads have to be done outside of EJBs. However, you can spawn a thread, it can instantiate an EJB, call its methods and consume the results, but no manipulations with threads inside EJBs.
ASKER
From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html#threads :
... Multithreaded applications are still possible, but control of multithreading is located in the container, not in the enterprise bean.