...
This commit is contained in:
parent
2049da3b13
commit
ed03f9c515
1 changed files with 3 additions and 3 deletions
|
@ -1908,12 +1908,12 @@ of object serialization. The first is to use a single transaction for
|
|||
each object modification, avoiding the cost of generating or logging
|
||||
any UNDO records. The second option is to assume that the
|
||||
application will provide a custom UNDO for the delta,
|
||||
which requires a log entry for each update,
|
||||
which increases the size of the log entry generated by each update,
|
||||
but still avoids the need to read or update the page
|
||||
file.
|
||||
|
||||
The third option is to relax the atomicity requirements for a set of
|
||||
object updates, and again avoid generating any UNDO records. This
|
||||
object updates and again avoid generating any UNDO records. This
|
||||
assumes that the application cannot abort individual updates,
|
||||
and is willing to
|
||||
accept that some prefix of logged but uncommitted updates may
|
||||
|
@ -1944,7 +1944,7 @@ by the page LSN so that unrelated updates remain independent.
|
|||
|
||||
Recovery work essentially the same as before, except that we need to
|
||||
use RSNs to calculate the earliest allowed point for log truncation
|
||||
(so as to not lose an older record update). In the implementation, we
|
||||
(so as to not lose an older record update). In practice, we
|
||||
also periodically flush the object cache to move the truncation point
|
||||
forward, but this is not required.
|
||||
|
||||
|
|
Loading…
Reference in a new issue