*** empty log message ***

diff --git a/Robust/Transactions/Notes/draft.pdf b/Robust/Transactions/Notes/draft.pdf
index 4e54ee3f00c7bb8b515578ccb03ab0f10b5e2983..b4c9713c2025efc87fd8e22d7d86c5efceb4c59a 100644 (file)
Binary files a/Robust/Transactions/Notes/draft.pdf and b/Robust/Transactions/Notes/draft.pdf differ

diff --git a/Robust/Transactions/Notes/draft.tex b/Robust/Transactions/Notes/draft.tex
index 01dc7c4b04bfb5938e7802b19e842ede7a9faa5e..18e088db4d85ac116df09549ce835712d592d5cb 100644 (file)
--- a/Robust/Transactions/Notes/draft.tex
+++ b/Robust/Transactions/Notes/draft.tex
@@ -118,7 +118,9 @@ We could also think of this as a state machine for each writedata operation. The
 
 \includegraphics[scale = 0.3]{hello2.png}\\
 
 
 \includegraphics[scale = 0.3]{hello2.png}\\
 

-\section{Commuting Operations}
+The final state for all $writedata$ operations is Absolute, since the write should be perfomed at a specefic offset eventually. However, depending on the prevuious circumstances the system would immediately prior to commit determine the offset or would have realized it earlier.\\ 
+
+\section{Guidelines for Implementaion}

 
 As we saw earlier in Rule 4, any two operations can commute across each other unless they are subject to one of the two conditions in Rule 3.\\  
 
 
 As we saw earlier in Rule 4, any two operations can commute across each other unless they are subject to one of the two conditions in Rule 3.\\  
 


@@ -129,8 +131,27 @@ $forced-readoffset(fd)$, as this would mean even if $\exists writeoffset \in OP_
 
 This stems from the definition of EndTransaction operation, and the state diagram. A $forced-readoffset$ can be issued at any place in $OP_T{i}$ however it would always precede the $writeoffset(fd) \in OP_{T_i}$ since this is last operation in $OP_{T_i}$ before $commit$.\\
 
 
 This stems from the definition of EndTransaction operation, and the state diagram. A $forced-readoffset$ can be issued at any place in $OP_T{i}$ however it would always precede the $writeoffset(fd) \in OP_{T_i}$ since this is last operation in $OP_{T_i}$ before $commit$.\\
 

-\textbf{guideline 2}: \emph{Commuting readdata Operations}:% A $readdata(fd_i.inode,offset_i, lenght_i) \in OP_{T_i}$ can go past a $commit_{T_j}$ if and only if $\not \exists writedata(fd_j.inode, offset_j, length_j) in OP{T_j}$ such that fd_j.inode= fd_i.inode and the two ranges (offset_i, offset_i + length_i) and (offset_i, offset_j + length_j) have an intersection.\\
+\textbf{Guideline 2}: \emph{Commuting readdata Operations}: A $readdata(fd_i.inode,offset_i, lenght_i) \in OP_{T_i}$ can go past a $commit_{T_j}$ if and only if \\
+
+1- $\not \exists writedata(fd_j.inode, offset_j, length_j) in OP{T_j}$ such that $fd_j.inode= fd_i.inode$ and the two ranges $(offset_i, offset_i + length_i)$ and $(offset_i, offset_j + length_j)$ have an intersection.\\
+
+ OR\\
+
+2- $\exists$ a set of $writedata(fd_j.inode,offset_j, lenght_j) in OP_{T_i}$ such that for all of them $writedata \rightarrow readdata$ and $fd_i.inode = fd_j.inode$ and the range $(offset_i, offset_i + length)$ is a subrange for a combiantion of ranges for these $writedata$ operations.\\
+
+\textbf{Axiom}: This follows imeediately from Rule 4 (1 and 2 are concrete representations for conditions 1 and 2 in Rule 3). However, it should be noted that whenever a $readata$ operation wants to commute across a $commit$ operation $\in T_j$, if $ \exists writedata \in OP_{T_j}$, the offset for the $wtitedata$ operation is known at this instant (according to the state diagram demonstarted below and regardless of whether $i = j$ or not), hence it would be trivial to see whether these $writedata$ operations intersect (or include in case they are in the same transaction as the $readata$) with the $readdata$ or not.\\
+
+\textbf{Guideline 3:} \emph{Reads Should be Validated At Commit Instant}:
+If an operation $a$ that "reads" some data $r_n$ (reads the data at some $t < t_{commit-of-the-transaction}$(the commit instant)), it should be ensured that the data $r_n$ is still valid in the actual file system at $t_{commit-of-the-transaction}$ (commit instant) or $T_i$ has to abort.\\
+
+\textbf{Axiom}: If the data is not valid anymore it means the data $r_n$ has been written since $t_{i-1}$. This implies at least one operation $b$ has written the data since the use and $b$ does not precede $a$ and $a$ precedes $b$. $b$ is either an operation in the same transaction or a different one. However, if $b$ is in the same transaction, then the data read is valid at commit instant by defenition. On the other hand, assume $b$ belongs to a different transaction namely $T_j$. Since $T_j$ should have already commited, according to Corrolary 2 all operation in $OP_{T_j}$ should precede those in $OP_{T_i}$, however, we know there is at least an operation $b$ that does not precede $a$ (since $a$ has not seen the "writes" made to $r_n$ by $b$). Hence, $T_i$ can not commit.\\
+
+
+\textbf{Guideline 4}: \emph{If Reads Are Valid At Commit Instant, the Transaction Commits}: If by applying Guideline 3 for $T_i$ it is ensured that $\forall r_i \in R{T_i}$ (all data read by $T_i$) is still valid at commit instant, then $\forall T_j \in T_{committed} T_j \rightarrow T_j$ and hence according to Rule 4 $T_i$ commits.\\
+
+proof: If all data read is still valid at commit instant, means all operation in the set of operations belonging to committed transactions, precede those in $T_i$ (since no writes have been seen), and consequently all those transactions precede $T_i$. Rule 5 ensures such transaction would be able to commit.\\ 
+
+

 
 

-%\textbf{Axiom}:\ This is 

 
 \end{document}
 
 \end{document}