Eu tenho um aplicativo Java EE em execução no GlassFish no EC2, com um banco de dados MySQL no Amazon RDS. Estou tentando configurar o pool de conexões JDBC para minimizar o tempo de inatividade em caso de failover do banco de dados.

Minha configuração atual não está funcionando corretamente durante um failover Multi-AZ, pois a instância do banco de dados em espera parece estar disponível em alguns minutos (de acordo com o console da AWS), enquanto minha instância do GlassFish permanece emperrada por um longo tempo (cerca de 15 minutos ) antes de retomar o trabalho.

O conjunto de conexões está configurado assim:

asadmin create-jdbc-connection-pool --restype javax.sql.ConnectionPoolDataSource \
--datasourceclassname com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource \
--isconnectvalidatereq=true --validateatmostonceperiod=60 --validationmethod=auto-commit \
--property user=$DBUSER:password=$DBPASS:databaseName=$DBNAME:serverName=$DBHOST:port=$DBPORT \
MyPool

Se eu usar umSingle-AZ instância db.m1.small ereiniciar No banco de dados do console, o GlassFish invalidará as conexões interrompidas, lançará algumas exceções e se reconectará assim que o banco de dados estiver disponível. Nesta configuração, recebo menos de 1 minuto de tempo de inatividade.

Se eu usar umMulti-AZ instância db.m1.small ereinicie com failover no console da AWS, não vejo nenhuma exceção. O servidor pára completamente, com todas as solicitações recebidas atingindo o tempo limite. Após 15 minutos, finalmente entendi:

Communication failure detected when attempting to perform read query outside of a transaction. Attempting to retry query. Error was: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 940,715 milliseconds ago.  The last packet sent successfully to the server was 935,598 milliseconds ago.

Parece que cada encadeamento HTTP é bloqueado em uma conexão inválida sem obter uma exceção e, portanto, não há chance de executar a validação da conexão.

O tempo de inatividade no caso do Multi-AZ é sempre entre 15 e 16 minutos, portanto parece um tempo limite de algum tipo, mas não foi possível alterá-lo.

Coisas que tentei sem sucesso:

tempo limite / recuperação de vazamento de conexãotempo limite / recuperação de vazamento de instruçãotempo limite da instruçãousando um método de validação diferenteusandoMysqlDataSource ao invés deMysqlConnectionPoolDataSource

Como posso definir um tempo limite em consultas bloqueadas para que as conexões no pool sejam reutilizadas, validadas e substituídas? Ou como posso permitir que o GlassFish detecte um failover de banco de dados?