Hi Joel, Another speculative idea is that there is a glitch with auto-commit setting. The connection might be in non-auto-commit mode but is not getting committed on em.close() for some reason and you are getting the same connection every time. Hence, because of transaction isolation, you don't see the values you insert manually. MySQL is treated by OpenJPA in a special way in that matter: because supportsMultipleNontransactionalResultSets is set to false in MySQL dictionary, OpenJPA switches auto-commit off on the connection. This can be seen in your log:
DEBUG - DataSource connection setAutoCommit to "false" What happens if you first fill the table and then run your program? Does it show the correct values? What happens if you encompass the query in a transaction? What happens if you set DBDicitonary property supportsMultipleNontransactionalResultSets to true? As for DHCP possible advantages of usage, there are one or two rare cases when it is used to unwrap the pooled connection and get the original one. One is using LOB streaming on PostgreSQL. You can browse the source of the dictionaries you are going to use to see if DHCP-specific handling is used. Even if it is, you should be able to override a method and adjust it to your pooling implementation. And if you are on a real JDBC 4 driver and pool, that should be handled nicely in a pool-agnostic manner. Greetings, Milosz > > > What about the inverse question: Is there a reason you don't want to use > > > DBCP? > > Good question! > > It's related to a recurring issue I was having, see this thread: > > http://openjpa.208410.n2.nabble.com/Issues-with-dhcp-connection-pooling-td5998390.html > > So I started experimenting with C3P0 to see if the problem went away. > Early days yet, but so far so good. > > (I also seem to remember many many moons (pre JPA) ago having issues > with dhcp that went away when I migrated to c3p0) > > J
