http://www.peertopatent.org/patent/20070198518/activity A system for implementing synchronized objects for software transactional memory comprises one or more processors and a memory comprising program instructions executable by the processor to implement a transactional-memory manager configured to coordinate memory access requests directed at the memory from a plurality of transactions. The transactional-memory manager records, within a collaborator record for a shared data object in the memory, identifications of a set of two or more transactions that have requested synchronization on the object. In response to a commit request from a given transaction of the set, the transactional-memory manager determines whether to commit or abort the given transaction based at least in part on the transactional states of other transactions in the set, examining the collaborator record to identify the other transactions. en-us Synchronized objects for software transactional memory 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). Mon, 15 Oct 2007 15:09:14 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory I'm not clear on what you mean by "parallel transactions"; in my experience that could refer to either (a) more than one separate transaction executing in parallel, or (b) one logical transaction within which are multiple "branches", sometimes aka a distributed transaction. In any case, I'm not aware of any prior art wherein separate *unrelated* transactions commit together. This might be subject to an "obviousness" argument based on similarities to known distributed transaction commitment techniques, wherein *related* subtransactions or pieces of a given transaction commit together. But I have some trouble seeing the utility of the proposed approach, which makes it harder for me to conclude that it would be an obvious extension. Fri, 02 Nov 2007 20:47:54 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory Can you please explain in more detail how [[prior art 88]] covers this application? I can see that one aspect of its goal is similar, i.e., lock avoidance, but the means and other goals appear to be different. This prior art teaches a scheduling mechanism that delays potentially conflicting transactions such that locks are not needed (because concurrency is prevented by this other means of delay). This does not seem to provide any higher concurrency, which is a goal and result of the application’s approach. Rather, lock avoidance in this reference is intended to avoid overheads associated with locking techniques. On the other hand, the application specifically allows concurrency, only preventing new accesses once existing accessors are already in the process of committing (and this seems a different criterion than the reference’s semantic concurrency control means). The application further provides for a co-commitment mechanism among the concurrent accessors, nothing like which is discussed in this reference. Fri, 02 Nov 2007 21:36:47 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory 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. Sat, 13 Oct 2007 12:26:57 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory Claim 1: A computing system including the transactional memory manager, with memory objects maintaining the current list of transactions that have accessed each memory object, and transaction resolution determined based on the states of all such related transactions. 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. Sat, 13 Oct 2007 12:27:51 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory Further classifying these claims appears to fall into two categories: 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 Tue, 16 Oct 2007 06:27:35 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory Regarding [[prior art 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. Fri, 12 Oct 2007 21:34:20 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory Doh! Make that [[prior art 80]]; P2P seems to use global numbering here not application-relative numbering. Fri, 12 Oct 2007 21:38:17 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory 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? Sat, 27 Oct 2007 16:53:07 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory 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. Tue, 13 Nov 2007 08:53:57 -0800 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory (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. Tue, 13 Nov 2007 09:26:02 -0800 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory This is a routine distributed commit, used in OODBs for at least 25 years of my personal experience. Renaming it "transactional memory" may be a good PR move but is hardly novel. Wed, 05 Sep 2007 13:58:51 -0700 http://www.peertopatent.org/patent/20070198518/discussion Synchronized objects for software transactional memory Would you be willing to chose a canonical publication and apply it to the claims? This would be quite helpful!!! Wed, 19 Sep 2007 17:50:24 -0700 http://www.peertopatent.org/patent/20070198518/discussion