Jump to content

Talk:Timestamp-based concurrency control

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 79.173.147.146 (talk) at 17:11, 5 January 2009 (Timestamp Rules). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

Yes, so why not have a go at it yourself. DerekP 13:34, 17 June 2006 (UTC)[reply]
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)[reply]
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)[reply]
No problem :) Nils Grimsmo 20:05, 17 June 2006 (UTC)[reply]

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)[reply]

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)[reply]

:Dunno.