topic Re: Accessing Business-Data via JPA before and after Timer in Alfresco Archive

Accessing Business-Data via JPA before and after Timer

bardioc — Mon, 10 Oct 2011 07:26:29 GMT

Hello,I've setup a very simple example of a process model that involves two Service-Tasks and a single Timer Catching Event. The model is as follows:[attachment=0]TestCaseA02.png[/attachment]Our customer's development rules require to separate the persistence database from the business database. Bot

Re: Accessing Business-Data via JPA before and after Timer

frederikherema1 — Mon, 10 Oct 2011 07:56:57 GMT

The jobexecutor responsible for executing the timers uses a different thread than the calling thread. However, it uses the same way of starting a transaction than normal execution of the process would do. The exception states:

Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.

Can't you locate your service in a different way?

Re: Accessing Business-Data via JPA before and after Timer

bardioc — Mon, 10 Oct 2011 08:05:25 GMT

The jobexecutor responsible for executing the timers uses a different thread than the calling thread. However, it uses the same way of starting a transaction than normal execution of the process would do. The exception states:
Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.

Can't you locate your service in a different way?

Hello, thanks for the fast response.

I'm not aware of any way doing this. WebSphere in special denies to do JNDI lookups in the "java:" context (where necessary things like java:comp/TransactionSynchronizationRegistry) are located from threads created outside of the J2EE applciation context. I would not even be able to lookup any datasource (e.g. java:comp/env/mydatasource) from threads outside the JEE context

Is there a way to modify the jobexecutor to utilize "allowed" constructs to create new threads, such as using the commonJ Workmanager approach provided by WebSphere? I've not digged into Activiti enough to see if there is a pluggable API to change the JobExecutor's way of handling threads till now . I'm willing to help in here.

I've actually played with the activiti-cdi version, but run into the same problem. After the jobexector ran, no bean context is available which is a dead end for us too

Thanks,

Heiko

Re: Accessing Business-Data via JPA before and after Timer

frederikherema1 — Mon, 10 Oct 2011 08:13:02 GMT

The thread-pool used by activiti is afaik not pluggable. However, the jobexecutor uses a ThreadPoolExecutor. You can potentially subclass the JobExecutor and add it to your ProcessEngineCOnfiguration(Impl).

Re: Accessing Business-Data via JPA before and after Timer

bardioc — Mon, 10 Oct 2011 13:42:56 GMT

The thread-pool used by activiti is afaik not pluggable. However, the jobexecutor uses a ThreadPoolExecutor. You can potentially subclass the JobExecutor and add it to your ProcessEngineCOnfiguration(Impl).

Hello again,

I've successfully implemented a commonJ-based POC for WebSphere that puts both, the job acquisition thread as well as the job execution within the JEE context by utilizing WorkItems/Work-Instances instead of direct threads in a threadPool. I currently do not use any of the pool features, as the work manager itself works as a queue based system.

My implemtation needs access to "private" API of the ProcessEngineConfiguration as I need to apply a different JobExecutor.

As the JobAquisitionThread implements Runnable, I've subclassed it and implemented the commonj.work.Work interface in this subclass. I'm not using the Runnable features at all, simply rely on the fact that the Work interface is affine to the Runnable interface. This is definitly not a good way, but I did not want to change too much here right now.

All in all the changes are:

replace the default JobExecutor with my own implementation

inside the JobExecutor replace the JobAcqusitionThread again with my own implementation

Using this constellation, I'm able to successfully optain an EntityManager (or any other JNDI resource) within the second service task (the one AFTER the timer). The transaction built by Activiti is used in this case.

As java is not an allowed attachment extention I cannot attach the modified versions of the WorkManager as well as the JobAcqusitionThread (Work). Keep in mind, this is a POC, e.g. the WorkManager JNDI name is currently hard-coded. If someone is interested in this, drop me a line.

Are there any plans to provide a customizable API for the JobExecutor? In JEE contexts it is generally forbidden to create own threads/threadgroups, etc. thus other application servers my suffer from this situation as well.

If there is any need/interest, I would be glad to help to open the API at this part and provide a pluggable version that is able to work with threads (for plain Java SE environments), commonJ (for WebSphere and others that support it) or any other implementation. I think its possible to generalize the problem here.

Drop me a line, if the team is interested. For now, I'll continue working with the POC to determine, if any other problems arise.

Best regards,

Heiko Kopp