Sure, it can be automated and defined by business rules. Storing 100k processes shouldn't be a problem for a production database. We can create a mix between admin and automated clean ups. 


On Mon, Mar 12, 2012 at 4:39 PM, Jeffrey DeLong <jdelong@redhat.com> wrote:
Both process instances and their associated tasks should be removed from the database once the process has complete. This needs to be automated, as users may start 100K process per day. Removing them manually from an admin console is absolutely not going to work.

FYI this was real flaw in jBPM3. Customers would start 100 of thousands of processes unaware that their database tables were growing (particularly if they did not turn off the audit log. After six months or so their system crawled to a halt because they had tens of millions of rows in their various tables.

Jeff


On Mar 12, 2012, at 10:21 AM, Mauricio Salatino wrote:

You should be able to clean up the tasks based on the users, to enable the users itself to clean up old and finished tasks.
The same for groups. These are basically extensions to the queries that you mention. We can create a very simple form that allow the admins to do these clean ups from the jbpm console administration tab.
We should have an unified way to do clean ups for processes as well right?

What about the HistoryLog? should we provide also a way to externalize the Human task information? 
Usually in that way we can delegate the clean ups (business cleanups) to the users that define how they want to externalize that information, and we inside the project can provide a way to do internal clean ups for the human task server and for the process instances that are canceled or ended.

My two cents..

On Mon, Mar 12, 2012 at 4:07 PM, Kris Verlaenen <kverlaen@redhat.com> wrote:
We could offer support for different strategies to clean up the task database.  What would be the options here?

 * Remove the task from the database when it is completed (and listeners have been notified)
  - this is probably too soon though, as some components might still need results (async for example)
 * Consider this as a clean-up job
  - remove completed tasks older than x days
  - remove completed tasks of completed process instances
  - ...

Any others ideas?

Kris

----- Oorspronkelijk bericht -----
Van: "Mauricio Salatino" <salaboy@gmail.com>
Aan: "Giovanni Marigi" <gmarigi@redhat.com>
Cc: jbpm-dev@lists.jboss.org
Verzonden: Maandag 12 maart 2012 16:32:42
Onderwerp: Re: [jbpm-dev] [jbpm 5.2] delete task rows when a process ends


Sure, that can be contributed back as an extension. If you can create a JPA query that do what your store procedure is doing we can provide a way to execute that, or let the user defines when and how he/she wants to do the clean ups.



On Mon, Mar 12, 2012 at 3:26 PM, Giovanni Marigi < gmarigi@redhat.com > wrote:


I created a stored procedure scheduled with a job that delete all tasks data related to a non existing process instance (it runs once a day)
I think anyway the problem must be faced because when you handle many process instances every day your JBPM database will grow fast and it becomes an issue in production.

Thanks,
Giovanni



----- Original Message -----
From: "Mauricio Salatino" < salaboy@gmail.com >
To: "Giovanni Marigi" < gmarigi@redhat.com >
Cc: jbpm-dev@lists.jboss.org
Sent: Monday, March 12, 2012 4:21:50 PM
Subject: Re: [jbpm-dev] [jbpm 5.2] delete task rows when a process ends

Not really. usually BPMS are good to keep track about that the work that has being done. The human task server will keep track and record all your human activities.
If you want to do some clean ups you will need to write the right sql queries against the human task server schemas


On Mon, Mar 12, 2012 at 2:43 PM, Giovanni Marigi < gmarigi@redhat.com > wrote:


Hi,
currently when a process instance ends, every task linked to this process (even if in state Completed) is not deleted from DBMS.
Is there a way to change this behaviour and delete all task data persisted on DBMS when a process ends?

Thanks,
Giovanni

--
Giovanni Marigi
Red Hat - JBoss Consultant -
email: gmarigi@redhat.com
Mobile: +39 3423175986
Office: +39 0687502315

Red Hat Italy
Via Andrea Doria 41m
00192 Roma - Italy
www.redhat.com

Prima di stampare, pensa all'ambiente ** Think about the environment before printing
_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev




--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar

- Salatino "Salaboy" Mauricio -

--
Giovanni Marigi
Red Hat - JBoss Consultant -
email: gmarigi@redhat.com
Mobile: +39 3423175986
Office: +39 0687502315

Red Hat Italy
Via Andrea Doria 41m
00192 Roma - Italy
www.redhat.com

Prima di stampare, pensa all'ambiente ** Think about the environment before printing




--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar

- Salatino "Salaboy" Mauricio -

_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev



--
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -

_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev




--
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -