Eric Davis

icon location Raleigh-Durham, NC icon location I write instructions for machines that do exactly what I tell them to do...regardless of whether or not those instructions actually match my intentions.

Results 15 comments of Eric Davis

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

I don't think this is a simple concurrency conflict handling issue. I am seeing the same behavior as the original poster. My application is attempting to use an EF context...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

There seems to be 2 issues here: 1. Why is the `init_connect` parameter executed for connections initiated from MySQL Workbench, but not for connections initiated from Pomelo/EF? 2. Why does...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

> Your best bet would be to use [DbConnectionInterceptor](https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.diagnostics.dbconnectioninterceptor), specifically `ConnectionOpened` or `ConnectionOpenedAsync`. @mguinness @lauxjpn - Why would this be required if the `init_connect` parameter is in place to execute...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

> Are you using root user in the connection string? If so [init_connect](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_init_connect) would be ignored. Otherwise you should create an issue in the underlying [MySqlConnector](https://github.com/mysql-net/MySqlConnector) library to determine why...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

Not sure why testing with a local DB would be relevant here? The behavior re: `init_connect` is inconsistent when connecting to the same DB from the same machine with the...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

Yes, but that doesn't explain why the same SQL executed against the same database using the same credentials executed from MySQL Workbench completes without error (and returns the expected values...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

Per this [doc](https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_row-count), `ROW_COUNT()` will not function reliably if using statement-based replication, but should with row-based replication. All my testing has been against clusters that have the `binlog_format` setting set...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

@bgrainger - Ok. The connection pooling theory makes sense. And adding `Connection Reset = false` to the DB conn string worked as you expected. Thank you for explaining the root...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

> You should try running that SQL under ADO.NET with [MySqlConnector](https://mysqlconnector.net/tutorials/connect-to-mysql/) directly instead of via Pomelo as it might help isolate the issue, You can also try changing the `UseAffectedRows`...

Set aurora_replica_read_consistency to "session" before DML commands .Net6.0 + EFCore6 + Pomelo6 + AWS Aurora (MySQL 5.7)

I tried to put a similar SQL operation together and execute it via MySqlConnector directly via the code below. But unfortunately, the `SELECT ROW_COUNT()` result is 0 and not 1...