Okay, this looked really good but I'm having trouble accessing the database
inside my Work object.
The errors I'm getting are:
org.hibernate.LazyInitializationException: could not initialize proxy - no
Session
or
IllegalArgumentException: entity not in the persistence context
Strangely I am not re-using objects from the other thread (that I know of) I
get the object using em.get() and then try to use that object.
Is there anything special I need to do in the Work object to set up the
persistence context and session? Does it need to construct its own copy of
the stateless beans and EntityManager somehow?
Brian Repko wrote:
>
>
> Glassfish does allow you access to the WorkManagerFactory and thus
> you can create a WorkManager. WorkManager allows you to create a
> Work object and put it on the queue - just like an HTTP request or
> an EJB method.
>
> Spring has this built into its TaskExecutor framework - with the
> GlassFishWorkManagerTaskExecutor. Spring extends the objects that
> you can put on the queue - plain old Runnables and does the conversion
> into Work objects for you.
>
> I believe that this will be part of the Java EE 6 spec but GF lets
> you access the objects now.
>
> We use this for background import tasks. Works like a champ.
>
> Brian
>
>
> ----- Original message -----
> From: "Dobes Vandermeer" <dobesv_at_gmail.com>
> To: users_at_glassfish.dev.java.net
> Date: Mon, 2 Feb 2009 10:18:33 -0800 (PST)
> Subject: Queueing jobs for processing in their own thread/transaction?
>
>
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Queueing-jobs-for-processing-in-their-own-thread-transaction--tp21795170p21817245.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.