Pre-Grant Publication Number: 20070198518
Track the progress of public participation in the review of this pending patent application, and view
application details. The menu on the right will help you navigate this patent application. Subscribe to
the community enables you to receive updates on this application via email so that you can easly follow recent activity.
LATEST PRIOR ART
| Date | Title | Reviewer |
|---|---|---|
| 11/28/07 | US20040010502A1: In-memory database for high performance, parallel transaction processing | Steven Pearson |
| 10/15/07 | US Patent 6289343 | Thomas Freund |
| 09/19/07 | SAGAS | Paul McKenney |
DISCUSSION
Steven Pearson (over 5 years 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.Thomas Freund (over 5 years ago)
The submission breaks down into 2 areas a.) those items related to the atomicity logic of a transaction service/manager and b.) those items related to the isolation logic of a transaction service. For the atomicity logic collaborators are no different that the well-known concept of parallel transactions (the transaction outcome processing itself is all established prior/existing-art). For the isolation logic the concept of a semantic access control (other than a lock) has been established in prior art (e.g. see patent number 6289343 for which this review is co-author).Steven Pearson (over 5 years ago)
Here's a summary of what I see here:
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.
PEER TO PATENT ACTIVITY
All
Discuss Patent Applications
14 comments posted
Size of Community: 9
14 comments posted
Size of Community: 9
Upload + Explain Prior Art
3 submitted
3 submitted
Annotate and Evaluate Prior Art
2 prior art ratings
3 citations
2 prior art ratings
3 citations
Research Prior Art
1 research notes
1 research notes
WHAT IS THIS APPLICATION ABOUT
0 days left




























