If you can get a hold of them they should work. Both, Stateless EJB and
UserTransaction can be stored in an instance variable because they are proxies
to the real objects.
Regards,
-marina
Dobes Vandermeer wrote:
> 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
>>
>>
>>
>
>