I see 'enq: JI - contention' when building multiple cubes/partitions

Question

Version 11.2.0.3
I can successfully build multiple partitions of a cube simultaneously by supplying the degree of parallelism that I want. I can also build multiple cubes and multiple partitions of multiple cubes by submitting separate jobs (one per cube) with parallelism set in the job (for number of partitions per job/cube).
My goal was to refresh 2 cubes simultaneously, 2 partitions in parallel each, so that 4 partitions total were refreshing simultaneously. There were sufficient hardware resources (memory and processes) to do this. I tried to submit 2 jobs, one for each cube, with parallel 2 on each.
What happens is that 3 partitions start loading, not 4. The smaller of the 2 cubes loads 2 partitions at a time, but the larger of the cubes starts loading only 1 partition and the other partition process waits with JI - contention.
I understand that JI contention is related one materialized view refresh blocking another refresh of the same MV. Yet simultaneous refresh of different partitions is supported for cube MVs.
Because I see the large cube having the problem but not the smaller one, I wonder if adding more hash partitions to the AW$ (analytic workspace) table would allow more concurrent update processes. We have a high enough setting for processes and job_queue_processes, and enough available threads, etc.
Will more hash subpartitions on the AW$ table allow for more concurrency for cube refreshes?

Answer 1

It looks like the JI contention was coming from having multiple jobs submitted to update the SAME cube (albeit different partitions). Multiple jobs for different cubes (up to one job/cube each) seems to avoid this issue. I thought there was only one job per cube, but that was not true.
Still, if someone has some insight into creating more AW hash subpartitions, I'd like to hear it. I know how to do it, but I am not sure what the impact will be on load or solve times. I have read a few sources online indicating that it is a good idea to have as many subpartitions as logical cube partitions, and that it is a good idea to set the subpartition number to a power of two to ensure good balance.