An error occurred fetching the project authors.
  1. 05 Jun, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#44672: Assertion failed: thd->transaction.xid_state.xid.is_null() · f3e86099
      Davi Arnaut authored
      The problem is that when a optimization of read-only transactions
      (bypass 2-phase commit) was implemented, it removed the code that
      reseted the XID once a transaction wasn't active anymore:
      
      sql/sql_parse.cc:
      
      -  bzero(&thd->transaction.stmt, sizeof(thd->transaction.stmt));
      -  if (!thd->active_transaction())
      -    thd->transaction.xid_state.xid.null();
      +  thd->transaction.stmt.reset();
      
      This mostly worked fine as the transaction commit and rollback
      functions (in handler.cc) reset the XID once the transaction is
      ended. But those functions wouldn't reset the XID in case of
      a empty transaction, leading to a assertion when a new starting
      a new XA transaction.
      
      The solution is to ensure that the XID state is reset when empty
      transactions are ended (by either commit or rollback). This is
      achieved by reorganizing the code so that the transaction cleanup
      routine is invoked whenever a transaction is ended.
      f3e86099
  2. 03 Mar, 2009 1 commit
  3. 21 Oct, 2008 3 commits
    • Davi Arnaut's avatar
      e139d9c7
    • Davi Arnaut's avatar
      Bug#28323: Server crashed in xid cache operations · b0d673fc
      Davi Arnaut authored
      The problem was that the server did not robustly handle a
      unilateral roll back issued by the Resource Manager (RM)
      due to a resource deadlock within the transaction branch.
      By not acknowledging the roll back, the server (TM) would
      eventually corrupt the XA transaction state and crash.
      
      The solution is to mark the transaction as rollback-only
      if the RM indicates that it rolled back its branch of the
      transaction.
      b0d673fc
    • Davi Arnaut's avatar
      Bug#28323: Server crashed in xid cache operations · ca53651d
      Davi Arnaut authored
      The problem was that the server did not robustly handle a
      unilateral roll back issued by the Resource Manager (RM)
      due to a resource deadlock within the transaction branch.
      By not acknowledging the roll back, the server (TM) would
      eventually corrupt the XA transaction state and crash.
      
      The solution is to mark the transaction as rollback-only
      if the RM indicates that it rolled back its branch of the
      transaction.
      ca53651d
  4. 26 Feb, 2007 1 commit
  5. 05 Oct, 2005 2 commits
  6. 13 Aug, 2005 1 commit
  7. 12 Aug, 2005 1 commit
  8. 05 Apr, 2005 1 commit
  9. 03 Apr, 2005 1 commit