Timeline for Managing concurrency when using SELECT-UPDATE pattern
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 22, 2012 at 21:29 | vote | accept | ErikE | ||
| Feb 12, 2012 at 23:14 | history | edited | ErikE | CC BY-SA 3.0 |
added 49 characters in body
|
| Feb 12, 2012 at 13:35 | answer | added | Martin Smith | timeline score: 14 | |
| Feb 12, 2012 at 11:46 | answer | added | Mark Storey-Smith | timeline score: 9 | |
| Feb 12, 2012 at 5:23 | comment | added | ErikE | We don't want a second client getting the old id value before it is updated to the new value by the first client. It should block. | |
| Feb 12, 2012 at 3:13 | comment | added | a1ex07 |
Just for clarification: do you want to prevent 2 clients from reading the same value or from issuing update that may be based on obsolete data? If latter, you can use rowversion column to check if the row to be updated hasn't been changed since it was read.
|
|
| Feb 12, 2012 at 2:47 | history | tweeted | twitter.com/#!/StackDBAs/status/168526623908446208 | ||
| Feb 12, 2012 at 1:54 | answer | added | A-K | timeline score: 12 | |
| Feb 12, 2012 at 1:06 | history | asked | ErikE | CC BY-SA 3.0 |