[Design of JBoss jBPM] - Re: Completion of Tasks results in deletion of Comments ente
by shekharv
Had a few more comments about how history is currently being tracked.
I am not aware of what the plan is in terms of providing history related features, for jbpm 4.xx similar to the lines of what was supported by jbpm3, hence my curiosity. Let me try to make my case here:
A typical way of using jbpm is to embed/integrate it into the client application. So the domain data of the client application is linked up to the domain of the workflow(process definition, process instance, tasks, etc).
The domain entity that is workflow enabled is linked up to process-instance. So this way jBPM is responsible for managing the workflow, keeping track of state, creating tasks, etc etc. Whereas the client domain would contain all the other data that is needed by the client application.
So you essentially are linking up two different pieces of data together. An insurance claim table would likely store the process_instance_id as one of it's columns,(and also vice versa, especially with the key based ids in jbpm4).
Now every step/task in the workflow, users of the client application might do one or more of the following:
1.) add comments to the task/process_instance.
2.) maybe even store some files.
3.) add some data to the workflow.
This is where history and the ability to track it comes into place. If there is any data that we want to store on the process-instance level, we can store it using the process-instance key.
Any data that we want to store on the task level, like associating which attachment was added at what step of the workflow, seems to be difficult to do in a straightforward manner currently. The task is being deleted from the task table, and is inserted into the JBPM4_HIST_ACTINST. At this point we lose the 'id' related to the task. So now way to associate the attachment with the task that it was added to.
I might be missing an angle here w.r.t doing this in v4. But it would seem that at least for the activity_history, we need to store the id of the activity so as to track items on the individual activity level?
This helps us to display a comprehensive history of what all happened, combining the data from the jbpm and client end and display it to the user.
Let me know your thoughts,
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242157#4242157
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242157
16 years, 9 months
[Design the new POJO MicroContainer] - Re: Parallel deployments
by kabir.khan@jboss.com
There was some talk on #jboss-dev about using an executor in the controller during bootstrap and then to avoid having too many thread pools configured to replace that with the system thread pool once that is installed.
Assuming that the system thread pool in AS trunk is the one deployed in thread-pool-jboss-beans.xml:
| <!-- Basic system thread pool deployment -->
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <threads xmlns="urn:jboss:threads:1.0">
| <thread-group name="SystemThreadFactoryGroup" group-name="System Threads"/>
| <thread-factory name="SystemThreadFactory" group="SystemThreadFactoryGroup"/>
|
| <!--
| ~ This thread pool is for SHORT-RUNNING tasks that block very little or not at all. Long-running
| ~ tasks submitted to this pool may cause starvation and extended blocking.
| -->
| <thread-pool-executor name="ThreadPool" thread-factory="SystemThreadFactory" queue-length="1000">
| <core-pool-size count="5" per-cpu="2"/>
| <max-pool-size count="10" per-cpu="3"/>
| <keepalive-time time="30" unit="seconds"/>
| <reject-policy name="block"/>
| </thread-pool-executor>
| </threads>
| </deployment>
|
I don't think this pool will work for the controller if my understanding of
| <reject-policy name="block"/>
|
is correct (that the caller blocks until a thread is available). The behaviour of the controller is to try to deploy asynchronous contexts via the executor, but if the executor is full to deploy the context in the calling thread. So I need a reject policy that behaves like ThreadPoolExecutor.AbortPolicy or ThreadPoolExecutor.CallerRunsPolicy for the pool handling asynchronous deployments.
So we have the choice of reusing the system thread pool but potentially blocking on asynchronous contexts (which I think kind of defeats the purpose), or having a small thread pool dedicated to deploying asynchronous contexts.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242133#4242133
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242133
16 years, 9 months