May 7th, 2009, 10:27 PM
rollback 30x slower than commit?
Apologies for perhaps being a bit off-topic, but I am hoping someone has a clue here:
We have a Spring/Hibernate/JTA/C3p0-based webapp that talks to MySQL 5.1 INNODB in READ_COMMITTED. We use optimistic concurrency, so periodically concurrent write attempts cause app-level StaleObjectStateExceptions that trigger rollbacks (and then we retry tx). We’ve added app-level caching and turned down our tomcat NIO thread count to just 8 (very little contention inside the app) but now we’re seeing that rollbacks appear to be up to 30x slower than commits?! Is that normal?
Here’s a typical TX:
Select * from users where name=”bob”;
Update users set visit_count=X where id=bobId and version=Y
When this tx is executed about 100 times/sec, appserver latency is about 10-15 ms per http request (including db time). However, when instead of commit a ‘rollback’ is issued, the latency spikes to 600-1100 ms (nearly all of that time in appserver appears to be spent waiting on db).
Given how few threads our tomcat executor now has, during a flood of concurrent writes, just a few thread waiting for 1s+ each basically render the appserver unresponsive and incoming requests start backing up very quickly.
So is that expected cost of a rollback? Can anything be done to speed it up? Has anyone implemented async rollback (though that's probably not a good idea)?