When my grails application faces high load, I encounter some SQLException :
java.sql.SQLException: Can't call commit when autocommit=true
This problem appears only when the number of connection on the application raises.
I'm using grails 1.2.2 and mysql 5.1
Does anybody already faces such kind of problem ?
Thanks in advance.
Related
I'm using yii2 framework, while I'm running it locally it shows an error driver not found. how can i fix it??
Database Exception – yii\db\Exception
could not find driver
↵
Caused by: PDOException
could not find driver
in G:\xampp\htdocs\edumetrix\vendor\yiisoft\yii2\db\Connection.php at line 687
.Are you using MySQL or another one?
You need install php-mysql or php-pdo
I am creating .net core 2.1 MVC application and using Azure database for MySQL DB 5.7.
I have read below links but seems they are applicable for MS SQL DB.
https://learn.microsoft.com/en-us/azure/mysql/concepts-high-availability
https://learn.microsoft.com/en-us/azure/architecture/best-practices/retry-service-specific
Transient handling for MySQL not possible? Help me link to MYSQL related similar pages.
A transient error, also known as a transient fault, is an error that will resolve itself. Most typically these errors manifest as a connection to the database server being dropped. Also new connections to a server can't be opened. Transient errors can occur for example when hardware or network failure happens.
Transient errors should be handled using retry logic. Situations that must be considered:
An error occurs when you try to open a connection
An idle connection is dropped on the server side. When you try to issue a command it can't be executed
An active connection that currently is executing a command is dropped.
The first and second case are fairly straight forward to handle. Try to open the connection again. When you succeed, the transient error has been mitigated by the system. You can use your Azure Database for MySQL again. We recommend having waits before retrying the connection. Back off if the initial retries fail. This way the system can use all resources available to overcome the error situation. A good pattern to follow is:
Wait for 5 seconds before your first retry.
For each following retry, the increase the wait exponentially, up to 60 seconds.
Set a max number of retries at which point your application considers the operation failed.
Read more here.
And you can read more on how to troubleshoot connection issues to Troubleshoot connection issues to Azure Database for MySQL here.
I am facing an issue where I am getting the following error:
CONTAINER:atg.repositoryException; SOURCE:java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: XA error: XAResource.XAER_RMFAIL start() failed on resource'ATGProductionDS_atg11':XAResource.XAER_RMFAIL: Resource manager is unavailable.
How do I solve this?
Do ATG connection threads get closed implicitly or do we have to close it explicitly?
Do ATG connection threads get closed after updateItem() and addItem() methods implicitly?
How can we close an ATG session thread explicitly?
There are potentially a number of causes for this issue. There is a support document in Oracle support portal which helps understand where the issue is (You will have to register for Oracle Support access)
Slow running query which is never timing out due to a misconfiguration
The timeouts for your datasource(s) are not setup correctly between WebLogic and the ATG application
Using
Java 1.6
JBoss AS 7.1.1
EclipseLink 2.4.1
JTA
Updated Question
How do I suppress the stacktrace being thrown by JBoss when I handle the error on my own in a try catch with flush?
Question
I'm trying to persist a entity using em.persist(entity). If no database constraints are being violated everything works fine. But if persisting the entity violates a unique constraints exceptions are thrown. I'm using transactions handled by JBoss so the exception is thrown from another thread.
I've already figured out that I can handle these exceptions globally by setting eclipselink.exception-handler in persistence.xml.
My question is how do I catch and handle these exceptions locally?
Calling em.flush() forces the statements to the database immediately and can be wrapped in a try catch block to handle exceptions before the commit occurs, though most persistence exceptions will mark the transaction for rollback anyway.
I have an interesting issue which I have not been able to resolve. I am using Play! 2.0.4 and using the integrated BoneCP connection pool to get the DB connections. However, for some reason, BoneCP keeps returning closed connections.
Database Server: Amazon RDS MySQL 5, default timeout settings (which should be 8 hours...)
My Play Datasource configuration looks as follows:
db.default.driver=com.mysql.jdbc.Driver
db.default.url="jdbc:mysql://{server}/{schema}?autoReconnect=true&useUnicode=yes&characterEncoding=UTF-8"
db.default.partitionCount=4
db.default.idleConnectionTestPeriod=2 minutes
I had assumed setting the idleConnectionTestPeriod to 2 minutes surely would have prevented BoneCP from returning closed connections, but it hasn't.
Every so often, I get the following stack trace in my logs:
Exception in thread "pool-6-thread-25" java.sql.SQLException: Connection is closed!
at com.jolbox.bonecp.ConnectionHandle.checkClosed(ConnectionHandle.java:350)
at com.jolbox.bonecp.ConnectionHandle.setReadOnly(ConnectionHandle.java:1089)
at play.api.db.BoneCPApi$$anon$1.onCheckOut(DB.scala:328)
at com.jolbox.bonecp.BoneCP.getConnection(BoneCP.java:514)
at com.jolbox.bonecp.BoneCPDataSource.getConnection(BoneCPDataSource.java:114)
at play.api.db.DBApi$class.getConnection(DB.scala:64)
at play.api.db.BoneCPApi.getConnection(DB.scala:273)
at play.api.db.DB$$anonfun$getConnection$1.apply(DB.scala:129)
at play.api.db.DB$$anonfun$getConnection$1.apply(DB.scala:129)
at scala.Option.map(Option.scala:133)
at play.api.db.DB$.getConnection(DB.scala:129)
at play.api.db.DB.getConnection(DB.scala)
at play.db.DB.getConnection(DB.java:50)
at play.db.DB.getConnection(DB.java:43)
at play.db.DB.getConnection(DB.java:29)
at com.edatasource.inboxtracker.tasks.TrackSiteEventActionTask.run(TrackSiteEventActionTask.java:23)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Does anybody know how I can fix this issue? Currently, I've had to wrap the DB.getConnection() in a try/catch and just catch the exception thrown by BoneCP and retry until I retrieve a valid connection. Seems like that should be unnecessary.
Thanks for any help.
Please try with 0.8.0-beta1. There was a bug related to this.