I have an EJB that needs to do schedule some work for itself, like sending
emails, processing certain records, etc. in their own thread and
transaction.
The reason I want to move them into their own thread and transaction is to
avoid holding locks for too long, avoid deadlocks, and avoid the possibility
that a job could throw an exception and cause all the other jobs to be
aborted or rolled back.
Up until now I've been using the TimerService and just scheduling each job
using a timer. However, I'm concerned that if I schedule too many timers I
might run into resource issues - for example, if the timers fire at the same
time, TimerService might try to create a thread for each one and they would
all create a transaction and then connect to the database - it's likely that
I'll run out of threads, database connections, memory or sockets.
I don't know how to predict or control how many threads the TimerService
might create at any time.
I thought I could use JMS for this but the JMS implementation with glassfish
v2ur2 is too buggy and I can't upgrade to 2.1 due to some weird classpath
issues in 2.1 I couldn't resolve.
Is there another good way to create a work queue that in processed in a
limited number of threads which can access my EJB in a transaction and do
some work?
Thanks!
--
View this message in context: http://www.nabble.com/Queueing-jobs-for-processing-in-their-own-thread-transaction--tp21795170p21795170.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.