Did you consider using Message Driven Bean, with multiple workers?
Uthiresh Narayanan
<uthiresh.narayanan@(protected)
PATNI.COM> cc:
Sent by: "A mailing Subject: Thread Pooling Design Issue
list for Java(tm) 2
Platform, Enterprise
Edition"
<J2EE-INTEREST@(protected).
SUN.COM>
11/18/2003 08:10 AM
Please respond to
uthiresh.narayanan
Hi everybody,
I have a business scenario, where there are multiple database
transactions
to be performed. Each transaction is a very heavy duty process and takes
almost 30-45 mins approx. Each of the process request is intiated by the
user and are added in a table. They have to be performed, not necessarily
one at a time. But since each process consumes a lot of DB resources, I
cant
have a *LOT* of these processes running at one time. The end of the process
is signalled when a flag is updated in that specific request entry in the
table.
I am planning to implement this as a thread pooling design where one thread
from the pool will service each request (ie. make a JDBC call and run the
stored procedure for the transaction). After servicing it will return to
the
pool and then service a new request. I can limit the number of concurrently
running transactions by knowing the number of threads runnning and so queue
up other requests in the DB table. I am interested in knowing other
techniques to decide to queue u these requests.
Now these transactions are very data intensive and it might be possible
that
the threads get struck in them for a long time.
One problem I forsee in this is if a thread get struck up in the database
process and never comes out (I cant keep a JDBC timeout coz I dont know how
much time each process might take!) so the thread becomes unusable and
moreover the request is unserviced. When I run this program on my
appserver,
after some time I get the StuckThreadMaxTime warning in the thread dump and
the appserver hangs up.(Each request is a row in the database and new
requests are identified by a simple N flag , a 'P' fl;ag for processing
and
after servicing they are made Y). Now this row will be stuck up in 'P'
state
forever.. I want to reset this flag to N so that it can be picked up by
some
other thread and start processing again.
Moreover if threads keep getting stuck the pool will eventually be empty. I
know that I can dynamically increase the size of the pool, but till when?
The number of user requests will be quite high.
What might be other issues with this design paradigm ? and thread pooling
in
general.
I know this is not a robust design technique, so would be glad to hear ur
suggestions.
I am running Weblogic 7.0 and Oracle 8i.
TIA.
reagrds,
uthiresh
===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".
===========================================================================
To unsubscribe, send email to listserv@(protected)
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected)".
