Pre-Grant Publication Number: 20070198518
Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO.
Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion.
Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original
ex. [[claim 1]] and [[prior art 2]].
Facilitator's Comment 
Action ItemShow without Noise
A transactional memory manager maintains a list of transactions (each comprising some related, finite set of operations in a thread of execution) that access a memory item protected ("synchronized") by the method. Each thread of execution lists the synchronized objects it accessed in its current transaction, and each object lists the set of transactions that accessed it since the last time it participated in transaction resolution. Transaction outcomes (commit or abort) are determined using a distributed commit type method, with the outcome of each participating transaction that accessed each involved memory item being consulted, and commit occurring only if all participating transactions (the maximal set of transactions that accessed any item also accessed by another transaction in the set) are ready to commit. (This is slightly different from traditional distributed commits, wherein a single transaction executes at multiple sites and each such site is a participant. Here, the participants are multiple transactions on one site.) Co-participating transactions can each see the as yet uncommitted changes made by the others. A means is provided to "seal" an object to prevent new transactions from accessing a memory item until the current participants' transactions are resolved.
Claim 2: Each transaction also keeps a list of all the memory objects it accessed, and uses this to expand the set of related transactions whose state must be consulted in order to determine the outcome of the transaction, by adding in all transactions that accessed any object also accessed by the given transaction.
Claim 3: Transactions in the fully expanded set of participants either all commit or all abort.
Claim 4: Performance optimization: If any participant is found to have already committed (indicating it already determined that the entire set could commit), another transaction in the set can immediately decide to commit (without completing a full survey of the states of all other participants).
Claim 5: Commit a participating transaction if all other participants are ready to commit.
Claim 6: Like claim 4, but for the abort case rather than the commit case.
Claim 7: Wait to decide the outcome of a participating transaction that wants to commit until either (a) all other participants are ready to commit, or (b) any other participant decides to abort.
Claim 8: Participating transactions see each others as yet uncommitted changes to shared memory objects.
Claim 9: Don't allow new transactions into the set of related participating transactions after any participant in the set requests to commit. Such transactions wait until after transaction resolution for the set of participants completes.
Claim 10: Adds a detail to claim 9: For each shared memory object there is a flag that is set when any transaction in its set of current accessors requests a commit, and that flag is consulted to make the determination whether to allow in a new transaction or to make the new transaction wait.
Claims 11 - 15: Reiterate claims 1, 2, 3, 4-6, and 7 as "method" claims (claims 1-10 are "system" claims).
Claims 16 - 20: Reiterate claims 1, 2, 3, 4-6, and 7 as "media" claims.
Transaction Atomicity model: 3-7, 13-15, 18-20
Transaction Isolation model: 1-2, 8-12, 16-17
Additional (prior-art) literature on the transaction model is contained in the book -
Transaction Processing: Concepts & Techniques by Jim Gray and Andreas Reuter, Morgan Kaufman Publishers, 1993, ISBN 1-55860-190-x (specifically Chapter 4: Transaction Models)
The topic had been previously covered in a number of (milestone) technical reports:
- Research Report IBM RJ2571(33471) 7/14/79, Notes on Distributed Databases, BG Lindsay, et.al.
- Tandem Technical Report 81.3, 6/81, The Transaction Concept: Virtues & Limitations, J. Gray
Regarding shared state among subtransactions, the apparent implication is that this is analogous to the shared memory items of the patent application. I find that quite a stretch. The patent application proposes to co-commit the fully expanded mesh of transactions that happen to touch memory items from the same set of memory items during those transactions life times. Sagas co-commits only those (sub)transactions that together constitute one logical long-lived transaction. Sagas says nothing about co-committing unrelated transactions that also happen to access any protected resource.
Sagas says nothing about co-committing unrelated transactions that also happen to access any protected resource ... that a (sub)transaction of the saga also accessed.