Menu
▾
▴
RE: re[2]: [Jdbm-developer] MC-DataSafe (in Persistent Store Inte rface).
|
From: Thompson, B. B. <BRY...@sa...> - 2006-02-16 19:02:03
|
Kevin, The point of concurrency control is to achieve concurrency that is consistent with _some_ serialization of the transactions being executed. So serializability refers to the fact that the execution of the transactions in parallel produces the same result _as_if_ they had been executed in some serial order. If the transactions are non-serializable then at least one must be aborted (and then retried). -bryan -----Original Message----- From: jdb...@li... on behalf of Kevin Day Sent: Thu 2/16/2006 1:57 PM To: JDBM Developer listserv Subject: re[2]: [Jdbm-developer] MC-DataSafe (in Persistent Store Interface). Bryan- But we aren't doing anything with serialing transactions - the whole point of MVCC is that it let's you run transactions in parallel with a greatly reduced chance for conflict (conflicts are only caused by writes). Technically one could serialize tx under MVCC, but it would be pointless - we might as well not be using MVCC at all. Maybe I'm missing some subtle point here? Two phase locking (if it can even be called that) under MVCC is quite a bit different than for other CC strategies. The vast majority of the literature on 2PL is centered on isolatin levels for read locks. Because a properly implemented MVCC system doesn't use read locks at all, all of that discussion is moot. I'm curious: Why the big push on serializing transactions? I could see some classes of applications where this could be an issue (e.g. real time data processing), but for the vast majority of cases the developer will wind up taking a huge performance hit. I suppose if we really wanted to that we could implement the capability of having read locks into jdbm - but running in that manner will completely defeat the purpose of MVCC. Personally, I'm more in favor of a simplified locking scheme. - K > Yes, but it depends on how you assign timestamps (or alternatively what serialization ordering you allow). If you accept the manner in which the timestamps were assigned to these transactions (at tx start) then this is a non-serializable pair of transactions. The notion of using 2PL to induce the serialization ordering is interesting and something that I want to work through. I presume that this will bear some relationship to what postgres is doing, but who knows what they actually did. -bryan -----Original Message----- From: <mailto:jdb...@li...> jdb...@li... on behalf of Alex Boisvert Sent: Thu 2/16/2006 12:11 PM To: Thompson, Bryan B. Cc: ''Kevin Day ' '; <mailto:jdb...@li...> ''jdb...@li... ' '; ''JDBM Developer listserv ' ' Subject: Re: [Jdbm-developer] MC-DataSafe (in Persistent Store Interface). Thompson, Bryan B. wrote: >I am sure that we will go around on this any number of times when getting >into an implementation. However, it is my understanding that if there is >a tx with a later timestamp, e.g., ts(t2)>ts(t1) then t2 can not read >data which t1 updates since the update would invalidate the read by t2 >(t2 would have failed to read the most current version as of the timestamp >when it started executing). In this case you can either abort t1 (the >writer) or you can block t2 (the reader) until t1 has completed. What >you can not do is permit a writer to write a version of x that has a >timestamp earlier than the most recent read of x -- since that would >invalidate the read by changing the value of x post-factor. > > t2 does not have to read the latest version of an object to commit and remain completely serializable. One way to look at this is to take the hypothetical case where t2 does not write anything. In that case, t2 can be considered to have happened before t1 even though it started after t1 (but before t1 committed). alex ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Jdbm-developer mailing list <mailto:Jdb...@li...> Jdb...@li... <https://lists.sourceforge.net/lists/listinfo/jdbm-developer> https://lists.sourceforge.net/lists/listinfo/jdbm-developer < ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdb...@li... https://lists.sourceforge.net/lists/listinfo/jdbm-developer |