Increase throughput for Grizzly and undertow by parallelizing DB access

[denkab]

1. Original configuration of connection for Hibernate in Grizzly-Jersey was highly inadequate. Bumped connection count to match claimed parallelism of test framework (256).
2. Parallelized DB operations for Grizzly-Jersey and undertow

[denkab]

Can not reproduce Mongo failure in my set up where I run it in a VirtualBox VM with 4 GB allocated. If I run the service by "./setup.sh" and then hit it with request, it returns just fine. If I run full blown test, the test terminates and the terminal session is "Connection to 127.0.0.1 closed by remote host."

Not my fault? :o)

[LadyMozzarella]

All of the mongodb tests tend to fail in Travis-CI. I ran your branch on the tests you changed through vagrant and it all looks good to me.

[LadyMozzarella]

It appears that this method (IdentifierLoadAccess.load) could potentially be returning the data from a cache based off of this description from the Hibernate JavaDoc:

If the instance is already associated with the session, return that instance, initializing it if needed.

This sounds like it could be a cache. If this is the case, we would need to ensure that it makes direct database access. Do you mind providing some clarification?

[denkab]

For query cache to work it needs to be enabled. Whomever first introduced this framework upheld the benchmark contract by supplying Hibernate configuration:
<property name="hibernate.cache.use_query_cache">false</property>