It sounds like the newer cloud SQL JDBC drivers for app engine (1) support connection pooling.
Our app uses Spring+Hibernate and we\'re trying to use one of the exi
We ended up solving this by using Tomcat DBCP (http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html). The problem with most other pools is that they use threading, which app engine's model prevent on frontend instances (long-lived threads that is).
This is an old question, but I wanted to provide what I believe is a more accurate answer. Google App Engine does allow applications to create threads through the use of their ThreadFactory
.
HikariCP allows configuring an external ThreadFactory
.
So, the configuration would go something like this:
import com.google.appengine.api.ThreadManager;
...
HikariConfig config = new HikariConfig();
config.setThreadFactory(ThreadManager.backgroundThreadFactory());
...
UPDATE: addressing the comment below about frontend instances... as noted elsewhere:
"Keep in mind that instances are created and destroyed dynamically, and requests are routed
to instances based purely on availability. ... There is no guarantee that requests of a
particular sort will always be handled by the same instance, nor is it assured that an
instance will still be around after a given request is handled. Outside of a request
handler, the application is not given the opportunity to rescue data from local memory
prior to an instance being shut down."
This substantially decreases the usefulness of connection pools on the frontend. In fact, it is a bad idea if the database is not in-memory, as it can create substantial churn of connections. With respect to local in-memory databases, not only are they fragile in the context of GAE, "connection overhead" is rarely a scalability factor warranting the use of a pool.
I created an example using Tomcat DBCP 1.4 for GAE frontend instances, which do not allow threads to live outside of request scope. This works with Java 7.
https://github.com/kennberg/appengine-java-connection-pool