After reading some more docs I realized that I can use the UserTransaction
API to create a transaction, I just needed to inject it into the bean
starting the work. I don't know if the bean and the UserTransaction are
guaranteed to be valid for use when the Work is run, though - the bean could
be passivated or something. I wonder if anyone knows whether it's okay to
keep a direct reference to a Stateless EJB from a Work instance this way?
Brian Repko wrote:
>
>
> Dobes,
>
> I would really recommend that you look at using Spring. Transactional
> stuff works - even against JTA transaction manager. I don't know about
> the timeouts/timers (lots of questions/issues posted here about EJB
> Timers) but you might look at Quartz with the Spring TaskExecutor
> framework on top of that.
>
> Your work is like a servlet - nothing transactional about it but it can
> start one. You just don't get container injection. But again, you can
> use Spring for that.
>
> Not sure if that is an option for you but I have similar requirements
> and things just work if I don't rely on the container for it ;-)
>
> Brian
>
>
> ----- Original message -----
> From: "Dobes Vandermeer" <dobesv_at_gmail.com>
> To: users_at_glassfish.dev.java.net
> Date: Mon, 9 Feb 2009 20:50:37 -0800 (PST)
> Subject: Re: Queueing jobs for processing in their own thread/transaction?
>
>
> It might be impossible. I've given up on the JMS stuff since it was buggy
> and the WorkManager doesn't support transactions as far as I can tell.
> However, now I have a new issue - when my timers run (I run a bunch of
> them
> to keep operation separate) the server and database start paging due to
> high
> memory use. Apparently I *do* need a way to restrict the number of these
> threads that are running.
>
> Maybe I'll go poking around in the glassfish source code and see if
> there's
> some private API I can use to workaround this and create a new
> transactional
> session in my Work instance somehow. I already poked around a bit but got
> scared of the code there, the code to invoke a timeout, which I thought
> would be a good example, seems to be pretty involved stuff. Nevertheless,
> having a utility class to run these jobs in a thread pool of my choosing
> would be very, very useful so it might be worth some brain pain to
> decipher
> the complexity of that subsystem.
>
>
>
> Brian Repko wrote:
>>
>>
>> Interesting, I'm not using EJB3.0 - I'm using Spring so all I need is to
>> get my ApplicationContext and I'm off and running. The LazyInitEx is
>> definately related to walking the object graph after the session is
>> closed.
>>
>> My guess is that putting Work on the queue doesn't get container objects
>> injected into it - you will probably need to get them some other way.
>>
>> Sorry - I don't know how to do that - anyone else?
>>
>> Brian
>>
>> ----- Original message -----
>> From: "Dobes Vandermeer" <dobesv_at_gmail.com>
>> To: users_at_glassfish.dev.java.net
>> Date: Tue, 3 Feb 2009 11:39:37 -0800 (PST)
>> Subject: Re: Queueing jobs for processing in their own
>> thread/transaction?
>>
>>
>> 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?
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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--tp21795170p21927689.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--tp21795170p21938612.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.