Hi Jeff, Here is a quick update on the JPA refactoring. I was finally able to discover the reason why one the of the Axis war tests was failing. It was due to the openjpa.FlushBeforeQueries setting being set to false and a JPA CorrelatorDAO persistent query being evaluated in memory as opposed to being executed on the database. OpenJPA was actually performing a DB query but it was not passing on any of the JPA Query parameters. Since there could be multiple transaction occurring simultaneously in the engine it is probably better to synchronize on the database as opposed to the JPA entity cache.
Now many more of the tests are passing but a few are left to be fixed. Some of the failed tests were due to the change I made to exclude the Hibernate derby database from the war file so I will probably need to back that change out. I am pretty confident that the core runtime engine is stable now after all my changes and the rest of the work to get the tests all passing again should just be maven tweaks. Regards, Aaron ________________________________ From: Jeff Yu <jeff.yuch...@gmail.com> To: dev@ode.apache.org Sent: Tue, March 30, 2010 12:18:57 AM Subject: Re: JPA DAO refactoring. Hi Aaron, comments inline. On Tue, Mar 30, 2010 at 2:31 AM, Aaron Anderson <aaronander...@acm.org>wrote: > Hi Jeff, > > Thanks for the response. I noticed that the integration tests were in the > svn trunk so I updated it to run the tests and while there were failed test > cases more passed than the git JPA branch so I introduced a regression issue > of some sorts. I will work on getting the branch into the same state as the > trunk. > OK, thanks. > > If possible I would like to leave all the testng integration tests as is. > If they do need to be modified I imagine I would only need to clean up > better after test execution in the test tear down. I don t believe the tests > can run in parallel due to port conflicts. > +1 > > Is there any documentation on the invocation sequences on the engine or any > hints on tracking down execution problems? I noticed there are multiple > layers of callables and futures and due to short timeouts I am having a hard > time tracking invocations through the call stacks. > To see what happens when a SOAP message for a deployed BPEL process is received by ODE, please look into the class org.apache.ode.axis2.ODEService. In the method onAxisMessageExchange every incomming message is processed. Within this method the method invoke of the class org.apache.ode.bpel.engine.MyRoleMessageExchangeImpl is invoked, then go to the BpelEngineImpl.onScheduledJob() method. you could set the mex.timeout according to http://ode.apache.org/user-guide.html#UserGuide-EndpointConfiguration --Jeff > > Regards, > > Aaron > > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
