ID_TOKEN_COUNTER is initialized with a non-thread-safe WeakHashMap, and when two PoolBackedDataSource instances are created in parallel the map can become invalid. This can result in another thread hanging in WeakHashMap.get.
The following thread dump was obtained using version 0.9.1.2. Version 0.9.5-pre3 uses HashMap instead of WeakHashMap, but the problem is still there.
"testng-JdbcMixedCacheStoreVamTest" prio=10 tid=0x00007fe8d817a800 nid=0x58ed runnable [0x00007fe8ba06a000]
java.lang.Thread.State: RUNNABLE
at java.util.WeakHashMap.get(WeakHashMap.java:355)
at com.mchange.v2.encounter.AbstractEncounterCounter.encounter(AbstractEncounterCounter.java:41)
at com.mchange.v2.c3p0.impl.C3P0ImplUtils.allocateIdentityToken(C3P0ImplUtils.java:192)
at com.mchange.v2.c3p0.impl.PoolBackedDataSourceBase.<init>(PoolBackedDataSourceBase.java:227)
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.<init>(AbstractPoolBackedDataSource.java:62)
at com.mchange.v2.c3p0.ComboPooledDataSource.<init>(ComboPooledDataSource.java:109)
at com.mchange.v2.c3p0.ComboPooledDataSource.<init>(ComboPooledDataSource.java:105)
at org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory.start(PooledConnectionFactory.java:35)
at org.infinispan.loaders.jdbc.mixed.JdbcMixedCacheStore.start(JdbcMixedCacheStore.java:70)
at org.infinispan.loaders.jdbc.mixed.JdbcMixedCacheStoreTest.createCacheStore(JdbcMixedCacheStoreTest.java:57)</init></init></init></init>
Fixed as of c3p0-0.9.5-pre4 (apparently reported near simultaneously by Keith Amling; i should credit you as well in the CHANGELOG.)