Results 1 to 3 of 3

Thread: rollback 30x slower than commit?

  1. #1

    Default 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:

    Set autocommit=0;
    Select * from users where name=”bob”;
    Update users set visit_count=X where id=bobId and version=Y
    Commit;
    Set autocommit=1;

    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)?

    Thanks!

    -nikita

  2. #2
    Join Date
    Jun 2006
    Location
    The Netherlands
    Posts
    13,695

    Default

    I know there is a overhead by using JTA and XA capable resources due to the synchronizations etc. But this seems a little overhead.

    One question that arises is do you really need JTA (do you have multiple transactional resources?) if not you could try a plain HibernateTransactionManager and see if that speeds things up (you could try it anyway to determine if there is an issue with JTA).

    Also I wonder how have you setup your transactions? Do you use transaction demarcation or something else? Maybe posting some code/configuration can help us solve the issue.
    Marten Deinum
    Java Consultant / Pragmatist / Open Source Enthousiast / Author


    Pro Spring MVC: With Web Flow
    Conspect

    Have you read the reference guide.
    Use the [ code ] tags, young padawan

  3. #3

    Default Pooling problem?

    Hi,

    Rollback should not be that expense (commit neither - even with JTA).

    I noticed that you are using C3PO - AFAIK that does not work with JTA so I strongly suspect that you have some configuration errors.

    Guy

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •