How did the timer events work?

[cweber]

Hi everybody,

Can somebody explain how the timer event is working in activiti. I want to understand how the timer were stored and how they are read.

In the Userguide I only find the information that you can enable the JobExecuter with <property name="jobExecutorActivate" value="true" />.
But it is set to default.

But what happens there?

Is the JobExecuter quering the database for ready timer events? Or how does it work?

[ronald_van_kuij]

Is the JobExecuter quering the database for ready timer events? Or how does it work?

If you want to know in detail, there is always the source, but asically that is what it does, yes.

[cweber]

All right, thanks for the answear. So I have to keep this service running even if my application sleeps to find out which timers are finished.

[trademak]

Hi,

The job executor is a thread that looks every couple of seconds if new jobs / timers need to be executed.
So yes, this needs to keep running to have the timers executed.

Best regards,

[cweber]

Hi. I know the question is a few days old but I'm not sure if I understand it right.
I use Xpages on Domino Sever to connect the activiti engine. So I have to create a managedBean that connects the runtime of activiti.
First I thougt to set this bean as application bean but because of 

MBSActivitiRuntime.getInstance().getProcessEngine().getIdentityService().setAuthenticatedUserId(pUser)
I think I get trouble with the authentication if I'm using this as a application bean.
So I change it to session. But this means every user get its own engine and all of the engines will run the thread that search for new timed events, right? So I get more threads with more logged in users, right?

Would it make sence to run an instance as application (a kind of server engine) were no user will logon and it just handles the threads.
And every user will start his/her bean as session without the threading for the timer events?

Hope I get it right!?

[frederikherema1]

Authentication is done on a thread-local base. So when you set the "setAuthenticatedUser()", be sure to clear the user in a finally-block around all the API-calls to ensure thread-pool threads' thread local userId doesn't stick after call to engine is completed.

It makes no sense to have multiple engines (one for each user), since current user is stored thread-based.

When a timer fires, it's executed by a job-executor thread. In this thread, by default, NO authenticated user is set. However, if you really want timers to be executed as a certain user, you can override the job handler. Good example of this is a class I implemented in alfresco, which uses the "assignee" of the task as authenticated user in alfresco. A similar approach can be created to call the setAuthenticatedUser() and clear it again before and after the time fires. This can be found on the Alfresco open mirror:

http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/repository/source/jav...

[cweber]

Thanks for the explanation.