Talk:Timestamp-based concurrency control

Thanks a lot guys for writing the "informal" part. Things are so much easier to understand in english than in math. Kudo Wikipdia ! 81.56.241.124

Recoverability

Shouldn't there be something on this page about why basic TO is not RC (or ACA or ST), and what you must do to make it so? -- Nils Grimsmo 11:45, 17 June 2006 (UTC)

Yes, so why not have a go at it yourself. DerekP 13:34, 17 June 2006 (UTC)

Sorry, I didn't mean to sound rude. This isn't my field, and I am not that familiar with the rest of the pages about scheduling, so I was afraid to write something wrong or use a "non-standard" notation. Feel very free to change what I've written or delete it :) Nils Grimsmo 17:10, 17 June 2006 (UTC)

LOL... You didn't sound rude to me at all but it looks like I came across as a bit abrupt, so I'm sorry. My intention was to encourage you to "have a go" and it was never meant to be critical. DerekP 17:53, 17 June 2006 (UTC)

No problem :) Nils Grimsmo 20:05, 17 June 2006 (UTC)

Timestamp Resolution

The edited text read "This is the minimum time quanta the system can represent, for example DOS was limited to two seconds.". However I wouldn't like the discussion to be limited to any specific operting system's limitations. The DOS example you mention refers to the timestamp on disk files, but DOS could achieve higher resolutions for other timestamps. The file limitation is based on the amount of space reserved in the FAT for the date-time value. Using the simple interrupt timer in DOS you could achieve 18.2 timestamps per second. Newer systems can easily get millisecond resolution. I'd like the discussion to reflect a more generic concept of timestamp resolution. DerekP 06:30, 6 March 2007 (UTC)

This resolution issue can easily be solved by using a counter instead of real time. If we want to order events, real time values are pretty useles s anyhow. 93.207.201.202 (talk) 23:55, 8 April 2012 (UTC)

Timestamp Rules

Sorry if I am being ignorant; this isn't my area of specialty. But suppose we have two items that must remain related, A and B. And suppose the following ensues: T1 T2 R1(A) R2(B) W1(A) R2(A) W1(B) ....

According to the rules stated on your page, the operation W1(A) will succeed, R2(A) will then also succeed, even though T2 has read an earlier version of B related to A. Then W1(B) will fail because of the more recent read R2(B), killing off T1 entirely, and then retracting the W1(A). But T2 now has a corrupt pair in its local cache.

This could only be corrected if the write timestamps are actual chronological time, and if the writer's transaction timestamp is also updated to this more recent time, to allow for possible re-reads of the just written data. That would then have disallowed the R2(A), which ought to have been the case. And that must also retract the read TS on B, further allowing W1(B) to occur.

eh? Dbmcclain (talk) 16:46, 8 September 2008 (UTC)

Formal part

Is $DEP(T_{i}).\mathrm {add} (WTS(O_{j}))$ correct or should it be $DEP(T_{i}).\mathrm {add} (O_{j})$? —Preceding unsigned comment added by 87.78.248.194 (talk) 21:57, 23 September 2010 (UTC)

Referencing

Don't know which came first yet, but there's an exact copy of this description at http://www.niuniv.com/NIUWeb/qbank/EVEN%20SEM/M.Sc%20IT/XCS010.pdf 130.243.141.218 (talk) 09:19, 18 March 2011 (UTC)

Thomas Write Rule

I think the use of Thomas Write Rule at the current version of this algorithm (formal version) doesn't work with the rollback that happens when a transaction must abort:

write:
	if WTS > TS
		skip (by Thomas Write Rule)

T2 sends write a
T1 sends write a
a written by T2
a not written by T1 because WTS = T2
T2 aborts, rolls back a 
T1 commits, thinking its value was written/

Problem: if T2 aborts, T1's write is relevant because T2 aborts and rolls back. Possible solution: add T2 to T1's DEP, but then we could have deadlock because of cycle in DEP relations

Should the algorithm here be changed to abort if WTS > TS, or should we just describe a real algorithm that's actually published somewhere :) ? 130.238.182.47 (talk) 11:18, 24 March 2011 (UTC)

This article needs to be rewritten anyway.... Do not rely on it. History2007 (talk) 19:05, 5 April 2012 (UTC)

Article quality

This article needs to be rewritten. I made a small change, but the time stamping concept is broader than just databases, and also applies to overall coordination of resources, etc. I can not work on it now but readers should be advised not to rely on it. History2007 (talk) 19:05, 5 April 2012 (UTC)