topic Re: Session and RequestScoped CDI from Job in Alfresco Archive

Session and RequestScoped CDI from Job

pkonyves — Wed, 02 Jul 2014 07:21:02 GMT

When there is a job that is executed by a Job executor, there is no CDI SessionScoped and RequestScoped context. A few of our business logic CDI beans are session or request scoped, but I also want them to work when executed by the JobExecutor. I was thinking of programmaticaly creating and activati

Re: Session and RequestScoped CDI from Job

bardioc — Wed, 02 Jul 2014 20:49:59 GMT

Hello,

let me assume that you are using a JEE container and do not use Activiti in Java SE with CDI. If so, you suffer from the default implementation of the job executor. This job executor creates so called unmanaged threads, which are no longer controlled by the container and thus lack any support for container based services such as EJB or CDI scopes.

Please refer to my post here: http://forums.activiti.org/comment/23760#comment-23760

I've described what we did to have a job executor with managed threads under WebSphere, but the solution is JEE 6 compatible for other containers as well.

Simply using interceptors won't help you, better just change the job executor in a way that it will keep respectively create managed threads. If the Application Server supports the so called ManagedExecutorService, this would be even easier than the described implementation, but still creating the scopes by hand won't help you, cause you lack other features the container provides, such as transactions and EJBs.

Best regards,

Heiko

Re: Session and RequestScoped CDI from Job

pkonyves — Thu, 03 Jul 2014 09:23:30 GMT

Hi Bardioc,

Thanks for your quick response. So as I understand, the essence to make the threads managed according to you is "lookup a local EJB via JNDI from our Job Executor and call a method annotated with @Asynchronous within it, passing in the ExecuteJobsRunable which is then executed within the asynchronous method"

One thing to note We don't use EJBs. What we use is: Activiti, CDI, JTA transaction manager. We try to avoid using EJBs (experimentally).

What I found:
- Transactions will be ok, because we set manually the TransactionManager in JtaProcessEngineConfiguration
- CDI bean lookup will be ok, because Activiti sets the beanmanager in BeanManagerLookup statically (In JavaDelegate tasks I usually use ProgrammaticBeanLookup)

Because of the lack of Servlet request, there is no SessionScoped and RequestScoped context which I wanted to overcome by creating and activating these contexts in DelegateInterceptor with the method explained here:

http://docs.jboss.org/weld/reference/latest/en-US/html_single/#d0e6020
a
Do you think it's feasible? Thanks

Re: Session and RequestScoped CDI from Job

bardioc — Thu, 03 Jul 2014 11:21:46 GMT

Hi,

I wonder why you want to avoid EJBs, but that is your decision. You would simply need a single EJB @Stateless bean with an @Asynchronous annotated method that you can call via CDI to pass in the ExecutableJobsRunnable.

For one thing, this will only give you RequestScope and ApplicationScope. SessionScope however is a completely different area, cause EJB will only provide this for Stateful beans. I wonder why you rely on SessionScoped beans for Activiti. What is your Session in that case? After becoming asynchronous via a Timer, there is no longer an associated session.

Otherwise, feel free to just start the scopes and see if that works. I wonder how entity management and transactions will work out. Simply adding a JTA transaction manager does not give you container based transactions, cause in unmanaged threads, no container will open up a transaction neither commit or rollback.

Btw. to start your scopes, refer to DeltaSpike Container Ctrl which helps you to start scopes pretty easily, rather than directly using Weld. Otherwise you might be incompatible with other application servers.

Re: Session and RequestScoped CDI from Job

pkonyves — Fri, 04 Jul 2014 13:32:43 GMT

All right, considering the future requirements where my approach might not be sufficient, I will go with your approach of @Async EJB method.

One other question: why did you change the AcquireJobRunnable to an EJB timer?