Peer to Patent, Community Patent Review

APPLICATION LIST|ARCHIVED APPLICATIONS|US PATENT CLASSIFICATIONS

Home > Discussion

Pre-Grant Publication Number: 20070198518

Synchronized objects for software transactional memory

Filing Date: February 14, 2006

Inventors: Victor Luchangco, Virendra Marathe

Assignee: Sun Microsystems, Inc.

Current U.S. Classification: 707, 707/008000

Discussion (5)

View: Date|Claims|Prior Art|Action Item|

Facilitator's Comment

Action Item

Show without Noise

Steven Pearson (about 1 year ago)

Regarding Prior Art Reference 1, at first blush I don't see this as being all that similar to sagas. Sagas are a collection of *related* subtransactions *spread out over time* within a long lasting outer transaction, whose effects are either all eventually committed or all aborted. In the case of a saga rolling back, it is not done directly (at least for already closed subtransactions, which are individually committed), but rather through the use of compensating transactions. The current application appears to me to marry a rather standard distributed commit protocol with something akin to the "uncommitted read" isolation level of the database world. Here, a group of *unrelated*, *concurrent* activities, being conceptualized as "transactions," can share access to a memory item and will all be rolled back in case something goes wrong in any one of them. The assumption seems to be that if any of the "transactions" that shares a memory item would have an incorrect outcome due to the sharing, or if any transaction was in some other way bad, all would roll back to avoid making persistent any effect or knock-on effect. But it's not clear to me that an incorrect outcome resulting from memory sharing would naturally be detectable by at least one of the sharers, so I'm not initially convinced that this approach is truly "safe". Anyway, I believe that the potentially novel piece has to do with the memory sharing aspect and not with the transactional aspect.

Steven Pearson (about 1 year ago)

Doh! Make that Prior Art Reference 80; P2P seems to use global numbering here not application-relative numbering.

Paul McKenney (about 1 year ago)

Later in the paper, they do describe concurrency -- so sagas -can- be concurrent. Also, in sagas, the subtransactions -can- commit individually, but are not -required- to. Also, a given saga's subtransactions might well share state, not?

Steven Pearson (about 1 year ago)

Yes, the paper does discuss (in sec. 8, Parallel Sagas) the possibility of concurrency between subtransactions of a saga. However, while not excluding the possibility that all (sub)transactions in a saga might run concurrently, the paper does not teach nor anticipate that all subtransactions might do so, nor does it teach the linking of individual (sub)transaction commits. Sagas are fundamentally designed support a collection of subtransactions that are spread out over time. The value sagas bring is in allowing at least one of the individual subtransactions to commit early, thus releasing resources prior to the final resolution of the overall saga. Having all subtransactions be concurrent with one another and commit all at the same time (presumably avoiding end-transaction and using only end-saga) is a degenerate case -- it gains nothing from using a saga; the original expression (anticipated to be a single long-lived transaction) would perform as well or better.

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.

Steven Pearson (about 1 year ago)

(my last sentence was abbreviated; should have said:)

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.

0 days left