I added a failing test case and a patch for ode1x branch in https://issues.apache.org/jira/browse/ODE-499
2009/1/28 Rafal Rusin <[email protected]>: > I tested it on ode1x (rev. 738300) and works fine. > Here's patch for 1x: > > Index: > dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java > =================================================================== > --- > dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java > (revision > 738300) > +++ > dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java > (working > copy) > @@ -99,7 +99,6 @@ > propMap.put("openjpa.ManagedRuntime", new TxMgrProvider()); > propMap.put("openjpa.ConnectionFactory", _ds); > propMap.put("openjpa.ConnectionFactoryMode", "managed"); > - propMap.put("openjpa.FlushBeforeQueries", "false"); > propMap.put("openjpa.FetchBatchSize", 1000); > > if (_dbdictionary != null) > > > 2009/1/27 Matthieu Riou <[email protected]>: >> On Sun, Jan 25, 2009 at 4:22 PM, Rafal Rusin <[email protected]> wrote: >> >>> >>> I had a similar warning in ODE 1.2 and 2.0 (trunk). It was: >>> >>> This query on type "class org.apache.ode.dao.jpa.MessageExchangeDAOImpl" >>> must load the entire candidate class extent and evaluate the query >>> in-memory. This may be very slow. The query must be executed in memory >>> because OpenJPA is configured with IgnoreCache=false and >>> FlushBeforeQueries=false and there are dirty instances that may affect the >>> query's outcome in the cache. >>> >>> A following patch resolves this problem and significantly speeds up >>> execution: >>> >>> Index: >>> src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java >>> =================================================================== >>> --- src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java >>> (revision 732587) >>> +++ src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java >>> (working copy) >>> @@ -96,7 +96,6 @@ >>> propMap.put("openjpa.ManagedRuntime", new TxMgrProvider()); >>> propMap.put("openjpa.ConnectionFactory", _ds); >>> propMap.put("openjpa.ConnectionFactoryMode", "managed"); >>> - propMap.put("openjpa.FlushBeforeQueries", "false"); >>> >>> if (_dbdictionary != null) >>> propMap.put("openjpa.jdbc.DBDictionary", _dbdictionary); >>> >>> >>> I'm doing now tests for JBI Layer and I did parallel invoke bpel process >>> (using <flow>), which hanged while above warning appeared. But with >>> Hibernate DAO and after applying this patch, everything worked fine. >>> >>> What about adding this patch to 1.2 & 2.0? >>> >> >> If it doesn't break any test, sure. >> >> Matthieu >> >> >>> >>> Regards, >>> Rafal Rusin >>> http://www.mimuw.edu.pl/~rrusin/ <http://www.mimuw.edu.pl/%7Errusin/> >>> >>> >>> >>> jbi joe wrote: >>> > >>> > Yes I am running 1.1.1 inside servicemix. >>> > Can I speed up process? When the message >>> > gets spit out, it is very slow, as it states in the >>> > INFO message... >>> > >>> > >>> > jbi joe wrote: >>> >> >>> >> >>> >> How do I speed up???? Also still cant get rid of the Message... >>> >> I did some testing and found that my BPEL is slow.. Especially during >>> >> the >>> >> time when the following message is spit out ( using 1.1.1 in >>> >> servicemix ) >>> >> >>> >> INFO - Query - This query on type "class >>> >> org.apache.ode.dao.jpa.ScopeDAOImpl" must load the entire candidate >>> class >>> >> extent and evaluate the query in-memory. This may be very slow. The >>> >> query >>> >> must be executed in memory because OpenJPA is configured with >>> >> IgnoreCache=false and FlushBeforeQueries=false and there are dirty >>> >> instances >>> >> that may affect the query's outcome in the cache. >>> >> >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/slowness-in-BPEL-tp15492817p21658762.html >>> Sent from the Apache Ode User mailing list archive at Nabble.com. >>> >>> >> > > > > -- > Rafał Rusin > www.mimuw.edu.pl/~rrusin > -- Rafał Rusin www.mimuw.edu.pl/~rrusin
