title: Can an autoincrement ID ever change from the mid-transaction value upon commit?
body: <p>The possibility of this happening seems extremely unlikely to me because of the problems it could cause, but I figured I'd ask the question anyway...</p>
  
  <p>Imagine a transaction where an autoincrement ID is involved and a value is assigned.  Prior to COMMIT, the involved code caches a copy of the assigned ID for later reference.  Then the transaction is committed.</p>
  
  <p><strong>Assuming no direct client intervention (deletion or altering of the record), is there any database or situation that would ever automatically alter the ID value immediately upon COMMIT, making the cached ID incorrect?  Is it always safe to cache the ID mid-transaction?</strong></p>
  
  <p>One hypothetical case where I can imagine this happening is if some RDBMS implementation inexplicably decided it was necessary to have gapless and time-dependent autoincrement values (since I see many examples of people wanting this).  In this hypothetical case, I can imagine some magical shuffling of IDs might be done to fill in gaps caused by post-ID-assignment rollbacks in another transaction (or other gap causer).  This would invalidate the cached value.</p>
  
  <p>Anyone know of such an implementation, or other cache killer?</p>