-
1. Re: Performance problem with JBPM 3.1.2
kukeltje Jan 15, 2010 2:30 PM (in response to sirivs)My first question : If all cancelled and closed TICKETS are triggered to endState, will I gain performance. And if I do, how should I proceed to push a selection of TICKETS to endState ?
Not sure, totally depends on where the delay is comming from. Running some analyzer on the database might show the slow queries (if you think it is related to that)
My second question : If I wish to drop TICKETS created in a year, how can I delete the related JBPM data from the database ?
Use e.g. a HQL to retrieve all ProcessInstances that you want to delete (query is effectively up to you) and then just do a delete via Hibernate. That will cascadingly delete all related data (afaik)
-
2. Re: Performance problem with JBPM 3.1.2
sirivs Jan 18, 2010 6:51 AM (in response to kukeltje)Thank you for the quick response !
In my first question, I just thought it could be a problem due to my process design (processInstance not going to endState). The bad performances are noticed on the production client server, but on my local dev server, I can't reproduce the big delays reported by the client. I still have to find exactly in which method the delays are coming from. So as you said I'll have to run some analysers on the client server and activate logs to read through.
When you say "analysers" do you have any good examples ?
For the second question, I can only say thank you ! I just didn't think it could be so easy. I'll try it out as soon as possible.
Regards,
Siri Douqué
-
3. Re: Performance problem with JBPM 3.1.2
kukeltje Jan 18, 2010 10:51 AM (in response to sirivs)Quick is my middle name ;-)
I'd start with the db first. Most have analyzers build in. And I know Hibernate (either directly or with some extension) has some options to log query performance. I'd try that first. Only when that does not yield anything, I'd try other profilers (like TPTT from eclipse)
Regarding the simplicitiy... That's jBPM...