On 05/10/2012 06:40 PM, Adrian Crum wrote: > I wanted to discuss this again. > > Some time ago I modified my local copy of OFBiz to execute the the ant > run-install task faster by using multi-threaded entity creation and > data loading. I don't remember what i was working on at the time, but > I needed the process to run much faster. > > Adam and I discussed my design and he said it sounded like it was > similar to SEDA (http://www.eecs.harvard.edu/~mdw/proj/seda/). > Actually, my approach was not that sophisticated, I just used a > consumer-provider design pattern based on a FIFO queue. > > Anyway, based on that conversation, Adam committed the multi-threaded > entity creation/data loading code > (http://mail-archives.apache.org/mod_mbox/ofbiz-commits/201106.mbox/%3c20110626025049.f302e2388...@eris.apache.org%3E). > The work Adam committed greatly improved the database creation/data > loading time. > > In this Jira issue, Adam mentions how transactions are tied to a > single thread. This is due to a fundamental weakness in OFBiz - the > use of ThreadLocal variables. In order to truly remove the bottlenecks > in OFBiz, we need to avoid the use of ThreadLocal variables - because > they prohibit handing off tasks to other threads. The Execution > Context proposed by David Jones some time ago is a step in the right > direction, but it uses ThreadLocal variables too.
My statement has *nothing* to do with ThreadLocal(well, at least not used by ofbiz). javax.transaction is for the *current* thread. When an xml import is requested, it *must* be done in the current thread, in the current transaction. It's not possible to suspend the transaction for the foreground thread, and resume it in the background(I tried). I may not have explained myself fully in the jira issue, or maybe you didn't understand. In any case, the rest of your explanation seems to not apply now. > So, we really need an object that is passed around the framework that > represents a TASK state, not a THREAD state - so that tasks can be > handed off to multiple threads. Transactions are tasks, so transaction > state would be contained in the object, not in ThreadLocal variables. > I believe that approach would solve the issue here.
