Adrian Crum wrote: > I multi-threaded the data load by having one thread parse the XML files > and put the results in a queue. Another thread services the queue and > loads the data. I also multi-threaded the EECAs - but that has an issue > I need to solve.
Well, there could be some EECAs that have dependencies on each other, when defined in a single definition file. Or, they have implicit dependencies with other earlier defined ecas. Like, maybe an order eca assuming that a product eca has run, just because ofbiz has always loaded the product component before the order component. This is a difficult problem to solve; probably not worth it. During production, different high-level threads, modifying different entities, will run faster, they are already running in multiple threads. Most ecas(entity, and probably service) generally run relatively fast. Trying to break that up and dispatch into a thread pool might make things slower, as you have cpu cache coherency effects to content with. What would be better, is to break up the higher levels into more threads, during an install. That could be made semi-smart, if we add file dependencies to the data xml files. Such explicit dependencies will have to be done by hand. Then, a parallel execution framework, that ran each xml file in parallel, once all of it's dependencies were met, would give us a speedup.
