Posted by
Adam Heath-2 on
URL: http://ofbiz.116.s1.nabble.com/Re-svn-commit-r1141288-ofbiz-trunk-framework-base-src-org-ofbiz-base-concurrent-ExecutionPool-java-tp3634223p3634327.html
On 06/29/2011 05:22 PM, Adam Heath wrote:
> On 06/29/2011 05:12 PM,
[hidden email] wrote:
>> Author: doogie
>> Date: Wed Jun 29 22:12:31 2011
>> New Revision: 1141288
>>
>> URL:
http://svn.apache.org/viewvc?rev=1141288&view=rev>> Log:
>> FEATURE: Add a global executor, to be used during config type parsing.
>
> I'm just waiting a little bit before checking in the next set, I'm
> letting buildbot do it's work.
>
> The next commit batch contains:
And now I have committed them.
I do have one more parallel commit; this time, Seed data parsing in
parallelized. However, it's rather convoluted, and I want to take
time to fix it. Below are the complexities:
EntitySaxReader has support for transactions. If the constructor is
used that allows you to set the timeout, and you set it to 0, then no
new transaction will be created. This means that whatever existing
transaction is active will be used(this is an important thing to
remember).
Intitially, I tried to have a background thread that would write to
the delegator. That is not valid, however, when we don't create our
own transaction. The writing has to be done in the original, parent
thread.
So, that means that the parser.parse() call has to be in the
background. Then, when end() is called, and either a singleton
create, or a batch of values is ready, it get's "posted" thru a
synchronous queue to the foreground thread.
Then, I noted that end() has support for transformations of the
xml(generally thru freemarker). It creates a new, internal
EntitySaxReader to do this. That then breaks again, because the
thread that creates the internal reader is running in the background,
and the transaction that gets used is not the same as the outer one
done by the initial caller.
Additionally, since the end() that creates the new internal reader is
already running the background, it makes no sense for the new reader
to also parse in the background. Just the queue that it posts to has
to be sent back to the original parent thread.
I do have all of the above problems solved, and the test cases all run
happily. However, I'd like to do some small refactors of the code
first, before committing the work as a whole. If you look at the
other commits I did today, I tweaked each class with several prep type
commits, so that the final parallelization feature was rather small
and easier to understand.