On 06/26/2011 04:19 PM, Adrian Crum wrote:
I'm not sure changing the value when using a RAM disk would make much difference. It seems to me multi-threading would benefit a system that has I/O bottlenecks.
By running on a ram disk, IO contention is much reduced(of course). Then using a high-core machine, allows me to test that the actual code has no issues.
Also, the JDBC driver itself could be a bottleneck. That's why I had a separate thread reading the entity model XML files - so one thread could be parsing XML while another one is waiting for disk I/O.
All that is good. I can verify that running these things in parallel speeds up both derby and oracle. It was initially developed on oracle, which doesn't have the aformentioned deadlock issue with foreign-keys.
We can come back to your staged idea. I have a helper class locally(without test cases yet), for batched staging, and shared pooling(hard to explain this latter part).
I also want to speed up service def parsing, ecas can run in parallel(they have to anyways, considering that there could have been multiple calling threads initially).
