Error : Cannot execute statement in a READ ONLY transaction - mysql

Question

I am using springboot application and connecting to Azure Mysql.
In a method call inside application there is an around spring aspect written which makes call to Azure MySql db.
Following is the squence of queries executed from the aspect and method
#Autowired
EntityManager entityManager
From Aspect : insert into <table name > values ();
For executing this query following piece of code is used
EntityManager newEntityManager = entityManager.getEntityManagerFactory().createEntityManager();
String nativeSql = "insert into table1 values('1','abc;)";
newEntityManager.getTransaction().begin();
try{
newEntityManager.createNativeQuery(nativeSQL).executeUpdate();
entityManager.getTransaction().commit();
} catch (RuntimeException e) {
newEntityManager.getTransaction().rollback();
}finally{
newEntityManager.close();
}
Read calls are done on databse using JPA with annotation
#Transactional(readOnly=true)
Next following piece of executed
EntityManager newEntityManager = entityManager.getEntityManagerFactory().createEntityManager();
String nativeSql = "update table2 set status='dead' where name='abc'";
newEntityManager.getTransaction().begin();
try{
newEntityManager.createNativeQuery(nativeSQL).executeUpdate(); //error occurs at this line
entityManager.getTransaction().commit();
} catch (RuntimeException e) {
newEntityManager.getTransaction().rollback();
}finally{
newEntityManager.close();
}
Following is the complete error
2019-02-10 23:18:00.959 ERROR [bootstrap,c577f32a3b673745,c577f32a3b673745,false] 10628 --- [nio-8106-exec-2] o.h.engine.jdbc.spi.SqlExceptionHelper : Cannot execute statement in a READ ONLY transaction.
But the same code works fine when it the application is connected with local mysql(MariaDb in my case).
This code works fine even if connected with Azure MSSQL.
But the error occurs when connected with Azure MySQL.

Answer 1

Not sure it's the right solution but I had the same problem with MariaDB and it was very confusing. I tried to track the state of the transaction using show variables WHERE Variable_name like 'tx_%' but it always showed tx_read_only as OFF - even when I actually ran read-only transaction. So I don't know how to find out whether the transaction is read-only.
But I pinpointed my problem to a rather obscure scenario. Before the problematic read-write transaction that is reported to be read-only I ran a different read-only transaction. Both used the same physical transaction and "read-only-ness" somehow leaked. But it failed when I used Connection.getMetaData() and then metaData.getColumns(...) in the first RO transaction. We needed to check the columns for a single table.
The problem did not appear, when I switched the transaction reading metadata to read-write, which makes sense if we suspect read-only leaking to another (logical) connection. BTW: we use combination of Hibernate and plain JDBC above a single Hikari connection pool, so this may be factor.
Later we changed the way to find metadata. We prepared a statement with SELECT returning nothing and then asking resultSet.getMetaData(). This was not only much faster for a single table (especially on Oracle, where it took like 5 minutes using Connection.getMetaData()) - but it did not cause the problem, not even when I read the metadata in read-only transaction.
So this was strange - the problem occurred when:
Specific database was used (MariaDB, but MySQL was fine and other types too).
When I read the metadata using Connection.getMetaData() in a read-only transaction (both conditions must be met to assure the failure).
The same wrapped (physical) connection was used for the next read-write transaction.
I checked that the very same JDBC connection was indeed used also in successful scenario when metadata was read from empty SELECT result set using read-only transaction. No problem with the read-write transaction. I thought the problem can be in handling the connection's meta data, I added resultSet.close() to the result set for MetaData.getColumns(), but no help here. In the end I avoided Connection.getMetaData() altogether.
So while I still don't know exactly where the problem is, I could go around it and assure that the connection seems to work for the next read-write transaction indicating no missing cleanup/read-only leak.
Another peculiarity was: We use SET TRANSACTION READ ONLY statement to start read-only transaction for both MySQL and MariaDB. It should work the same way on both databases. When I switched to START TRANSACTION READ ONLY instead, it worked fine. Even when I used the "wrong" way to access table metadata.
But then, sorry, it does not indicate why the OP has problem on MySQL.