Neilk1021 commented on PR #6238: URL: https://github.com/apache/texera/pull/6238#issuecomment-4918790327
For future reviewers, small notes on *why* I reverted my changes to with transaction and implemented Hikari pooling for `MockTexeraDB`. First, my earlier `withTransaction` changes modified production business logic and added weight purely to work around a test bug. That was a stop-gap fueled by my own misdiagnosis of where the bug was actually coming from, so I've reverted `withTransaction` back to the jOOQ-native form. The real root cause: backing `MockTexeraDB` with a single physical connection creates a failure mode that doesn't exist in production. Under concurrency, multiple threads share one connection and race on its autocommit state, producing flaky `Cannot commit transaction` failures. Production uses a pooled DataSource where each thread gets its own connection, so it never sees this. Fixing it at the harness layer makes the test topology match production and lets `withTransaction` stay as the clean one-liner. On test speed: the physical connection was never the bottleneck. The expensive part was spinning up EmbeddedPostgres instances, so this PR boots one shared instance per JVM and gives each suite its own isolated database via a cheap CREATE DATABASE. Pooling adds negligible per-op overhead on top of that. On the benchmark deltas: they're within the harness's known noise (single-run, and the flagged reds are p95/p99 off ~20 samples, which is dominated by tail variance). There's also no code path from a test-only change to the Arrow Flight data plane, so I don't believe these reflect a real regression. However, I'm happy to re-run if useful. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
