Timeline for Why are timestamps not always increasing with concurrent inserts?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 19, 2015 at 19:04 | vote | accept | Paul Williams | ||
| Nov 25, 2013 at 18:36 | comment | added | Hannah Vernon♦ | If the cached timestamp is 5, the most recent timestamp is 7, but there are rows with a timestamp of 6, surely the cache should simply get all rows with a timestamp higher than 5? And use the highest new timestamp (7) as the new cached timestamp value... | |
| Nov 25, 2013 at 17:25 | comment | added | Paul Williams | @MaxVernon - Actually, this could be a problem for us even in READ COMMITTED isolation. If the second transaction finishes before the first with its higher timestamp values, then our cache will retrieve it. Unfortunately, since its maximum known timestamp is now higher than all of the first transaction's records, our caching code will never retrieve any of them. | |
| Nov 25, 2013 at 17:08 | comment | added | Paul Williams | @Kin - Martin Smith is correct, the function is essentially a tally table. | |
| Nov 25, 2013 at 17:06 | history | edited | Paul Williams | CC BY-SA 3.0 |
included code for function dbo.fn_GenerateNumbers
|
| Nov 25, 2013 at 16:55 | comment | added | Paul Williams | @MaxVernon - The concern stems from an issue I found in our own software. One of our queries that deals with caching data was doing a dirty read. If this read happened to read a higher timestamp from a second thread, the cache would never synchronize with the rest of the records from the first thread. While this was a problem in our software, it made me question why the database timestamps would behave this way. | |
| Nov 25, 2013 at 16:46 | history | edited | Paul Williams | CC BY-SA 3.0 |
added 8 characters in body
|
| Nov 23, 2013 at 10:35 | comment | added | Martin Smith | @Kin - Sounds like it is basically this. dba.stackexchange.com/questions/7233/… | |
| Nov 23, 2013 at 4:01 | answer | added | Sebastian Meine | timeline score: 8 | |
| Nov 23, 2013 at 2:02 | comment | added | Hannah Vernon♦ | Interesting question, but what is the underlying concern? | |
| Nov 23, 2013 at 1:51 | comment | added | Kin Shah |
@PaulWilliams If you can post the code for dbo.fn_GenerateNumbers that will be helpful in a repro.
|
|
| Nov 23, 2013 at 1:22 | comment | added | billinkc | Augmenting Phil's comment, timestamp merely tracks whether a row has been modified. See picture First insert created the ts values. Application retrieves the data locally, modifies it and prior to updating verifies its ts matches what's on the current record. Meanwhile, a faster person edited those rows and voila, timestamps don't match. The actual value of a timestamp means nothing | |
| Nov 23, 2013 at 1:02 | comment | added | Philᵀᴹ | "The rowversion data type is just an incrementing number and does not preserve a date or a time. To record a date or time, use a datetime2 data type." -- or maybe I'm missing something? Quoted from the link at the top of your answer. | |
| Nov 23, 2013 at 0:58 | history | asked | Paul Williams | CC BY-SA 3.0 |
