September 2008 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: Expression Evaluation in ActionHandler Properties

by alex.guizar＠jboss.com

Filed JBPM-1752. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176923#4176923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176923

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Multiple 1PC resources in enterprise

by alex.guizar＠jboss.com

anonymous wrote : Cool... one mind, one vision. Either Tom or Alex is clairvoyant ROFL! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176904#4176904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176904

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Multiple 1PC resources in enterprise

by kukeltje

"alex.guizar(a)jboss.com" wrote : anonymous wrote : on the migration to ejb3: i don't think that is appropriate on jBPM 3. we can consider this on jBPM 4. | +3.1415926 | ejb3 is definitely a proposal for jbpm 4. I volunteer for that. | Aren't you 0.0000001 off? Oh and 'volunteer'? Besides the 40+ hours you make for JBoss? haha "alex.guizar@jboss.com/tom.baeyens(a)jboss.com" wrote : | anonymous wrote : i would guess the whole purpose of an appserver is to take care of making a global transaction out of XA transactional resources, no ? even if we would use different DSs. | managing a global/distributed transaction is the app server's business indeed, except that (1) some databases such as HSQL and (correct me if I'm wrong) MySQL do not provide XA data sources and (2) the EJB timer service's support for 2PC relies on its underlying data source, which affects the EntitySchedulerService. JMS's 2PC support does not rely on the underlying data source's XA capability and therefore the JmsMessageService is unaffected. Cool... one mind, one vision. Either Tom or Alex is clairvoyant View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176880#4176880 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176880

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: The PostgreSQL Issue

by alex.guizar＠jboss.com

I just found evidence that the leaked connections can certainly be related to the growing number of processes. anonymous wrote : The PostgreSQL server uses one process per connection so you should provide for at least as many processes as allowed connections, in addition to what you need for the rest of your system. This is usually not a problem but if you run several servers on one machine things might get tight. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176751#4176751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176751

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Multiple 1PC resources in enterprise

by tom.baeyens＠jboss.com

anonymous wrote : i would guess the whole purpose of an appserver is to take care of making a global transaction out of XA transactional resources, no ? even if we would use different DSs. managing a global/distributed transaction is the app server's business indeed, except that (1) some databases such as HSQL and (correct me if I'm wrong) MySQL do not provide XA data sources and (2) the EJB timer service's support for 2PC relies on its underlying data source, which affects the EntitySchedulerService. JMS's 2PC support does not rely on the underlying data source's XA capability and therefore the JmsMessageService is unaffected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176750#4176750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176750

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: The PostgreSQL Issue

by alex.guizar＠jboss.com

anonymous wrote : Another concern is that the number of postgresql processes is increasing unexpectedly to over 100 This is probably related to connection pooling. See the comments on JBPM-1131. I cannot tell whether the leaked connections are causing PostgreSQL to fork new processes, but is definitely a starting point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176748#4176748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176748

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Multiple 1PC resources in enterprise

by alex.guizar＠jboss.com

anonymous wrote : on the migration to ejb3: i don't think that is appropriate on jBPM 3. we can consider this on jBPM 4. +3.1415926 ejb3 is definitely a proposal for jbpm 4. I volunteer for that. anonymous wrote : i would guess the whole purpose of an appserver is to take care of making a global transaction out of XA transactional resources, no ? even if we would use different DSs. managing a global/distributed transaction is the app server's business indeed, except that (1) some databases such as HSQL and (correct me if I'm wrong) MySQL do not provide XA data sources and (2) the EJB timer service's support for 2PC relies on its underlying data source, which affects the EntitySchedulerService. JMS's 2PC support does not rely on the underlying data source's XA capability and therefore the JmsMessageService is unaffected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176743#4176743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176743

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Major refactoring of the jbpm3 core test suite

by tom.baeyens＠jboss.com

deleting deployed definitions and checking if no records are left seems more error prone to me then just deleting all records in the db. but what you suggest works and that is the most important part. it's your call. i don't think the same solution will hold in jbpm 4 as i'm not sure that we'll have the same behaviour for deletion of process definitions. i think it might be wise to have two separate methods: deleteAllExecutions and deleteProcessDefinition. Then deleteProcessDefinition could throw an exception if process executions are still around. but that decision is for later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176685#4176685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176685

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Major refactoring of the jbpm3 core test suite

by kukeltje

I made some tests for some more complex jBPM usage and had to adapt them to what Thomas did (great job). Just deleting each generated processDefinition seems to delete all related processInstances, logs etc... so it was as simple as putting a try/finally around my test and indeed keeping track of what processDefinitions I deployed. If we adapt all tests to deploy via a deployProcessDefinitions method of the AbstractDBTestCase, it can keep track of all of them and automatically undeploy/delete at teardown. That would get rid of all try/catches again. The only thing is that the System.exit stops the tests, but Eclipse thinks JUnit is still running... Initially (when I updated from SVN, I was confused.... The FIXME can have a little more explanation, but now I know this, it does not realy bother me View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176635#4176635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176635

16 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Major refactoring of the jbpm3 core test suite

by thomas.diesler＠jboss.com

> can you explain how you make sure that each test starts from a clean DB ? The system exits on tearDown() when there are records left in the DB. A test that does this is invalid and not allowed to enter the test suite. > turned out to be very impractical and tedious indeed > those are typically very hard to find not if the invalid test is immediately rejected > so far, clearing the whole db has proven to work well If so, there should be successful hudson runs that show that. Rather the opposite is true. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176571#4176571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176571

16 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev September 2008