- 06 May, 2005 6 commits
-
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
If a threaded transaction manager ever passed None to the Transaction constructor's `synchronizers` argument, then synchronizers registered later in the same transaction were invisible to the transaction, and so their afterCompletion() methods wouldn't get called when the transaction ended.
-
Tim Peters authored
-
Tim Peters authored
This is effectively a beta release, but I don't want to take the time to do a full-blown release right now.
-
Tim Peters authored
whenever TransactionManager.begin() is called. Connection implements that, and changes its ISynchronizer afterCompletion() method, to call sync() on its storage (if the storage has such a method), and to process invalidations in any case. The bottom line is that storage sync() will get done "by magic" now after top-level commit() and abort(), and after explicit TransactionManager.begin(). This should make it possible to deprecate Connection.sync(), although I'm not doing that yet. Made a small but meaningful start by purging many sync() calls from some of the nastiest ZEO tests -- and they still work fine.
-
- 03 May, 2005 1 commit
-
-
Tim Peters authored
Added more comments. Changed some comments to English. Renamed some attributes and methods for clarity. Switched to using a Python WeakKeyDictionary instead of rolling our own out of a Python dict and raw weakrefs.
-
- 02 May, 2005 1 commit
-
-
Tim Peters authored
Added new test checkSubtxnCommitDoesntGetInvalidations to verify that a longstanding bug in subtransaction commit is repaired. Jim (Fulton) discovered this in ZODB 3.4's code, while implementing savepoint/rollback. Same bugs had been there at least since ZODB 3.1. Also added news about the bug.
-
- 28 Apr, 2005 1 commit
-
-
Tim Peters authored
-
- 27 Apr, 2005 2 commits
-
-
Jim Fulton authored
-
Jim Fulton authored
for savepoint management are: - All savepoints for a transaction should be invalidated when the transaction commits or aborts - If a savepoint is rolled back, then all savepoints after it within a transaction must be invalidated. We previously implemented these requirements by organizing transaction savepoints into a doubly linked list. This was overkill. We didn't have need for such fine-grained ordering. This strategy had the disadvantage that it kept all savepoints around until the transaction ended. Savepoints could be expensive to keep and it's possible that some applications could keep a lot of them. The new stragey is to: - Keep weak references to savepoints. We can forget about savepoints that the application isn't using. Any resources used by these savepoints can be freed. (We have to keep a strong reference to the last savepoint used for a subtransaction.) - We assign indexes to savepoints within a transaction. When a savepoint is rolled back, in addition to invalidating that savepoint, we also invalidate savepoints with a higher index. A side effect of this change is that code using the savepoint API should interfere less with code using subtransactions. Of course, we really need to phase out code that uses subtransactions. It is likely that we can leverage this change in strategy to speed creation of ZODB connection savepoints. Creating a ZODB connection savepoint now requires copying the savepoint storage index. This index could become large. If applications aren't holding on to old savepoints, then it is possible that we could avoid this copy.
-
- 26 Apr, 2005 3 commits
-
-
Tim Peters authored
-
Tim Peters authored
-
Florent Guillaume authored
returns an iterable producing the registered beforeCommit hooks.
-
- 25 Apr, 2005 8 commits
-
-
Tim Peters authored
-
Tim Peters authored
-
Jim Fulton authored
just the savepoint being rolled back because later savepoints might involved data managers that hadn't joined when the savepoint being rolled back was created. Now, when a data manager joins and we have savepoints, we create a data manager savepoint for the new data manager and add the datamanager savepoint to all previous transaction savepoints. Note that this data manager savepoint can be a special savepoint that just calls abort on the data manager when it is rolled back.
-
Tim Peters authored
-
Tim Peters authored
-
Tim Peters authored
-
Jim Fulton authored
Removed the freeme argument. This argument is part of the implementation, not the public interface. Removed the subtransaction argument. Although it is still supported, it isn't part of the pblic interface. Added missing documentation of the savepoint method.
-
Jim Fulton authored
-
- 24 Apr, 2005 9 commits
-
-
Jim Fulton authored
Added demonstration of transaction non-commitability after savepoint or savepoint rollback failure. Updated "previous commit failed" error to "previous operation failed".
-
Jim Fulton authored
transaction savepoints. Updated some interface declarations.
-
Jim Fulton authored
-
Jim Fulton authored
-
Jim Fulton authored
Once we start using savepoints, we need to make sure that all data are committed through the savepoints. Otherwise, things can get committed in the wrong order, leading to conflicts.
-
Jim Fulton authored
savepoint, then modified and then aborted. Also added missing code to clear registered objects when a savepoint was rolled back.
-
Jim Fulton authored
(And also added interfaces and rearranged some code to hopefully make it easier to read.)
-
Jim Fulton authored
-
Jim Fulton authored
-
- 23 Apr, 2005 1 commit
-
-
Tim Peters authored
Also fiddled things to make this look like release 3.4a4.
-
- 22 Apr, 2005 3 commits
-
-
Tim Peters authored
In addition, repaired the useless default logging in runzeo.py. Here's Sidnei's Zope 2.7 checkin comment: * Borrow Zope's 'Signal' mechanism for Windows, if available, to implement clean shutdown and log rotation handlers for Windows. * Back to creating a .PID for ZEO, so external programs that wish to set the 'signal' can get the PID and therefore derive the signal name. Currently only necessary on Windows but created on all platforms which implement os.getpid(), as long as the 'pid-filename' option is set, or the 'INSTANCE_HOME' environment variable can be found.
-
Tim Peters authored
DemoStorage: Added implementations for registerDB() and new_oid(). As Tres discovered the hard way, wrapping a ZEO client storage as a DemoStorage base storage yields insane behavior otherwise. BaseStorage.new_oid(): Rewrite to eliminate recursion, and hence also the need for the undocumented and irregular `last=` argument. Other: removed the `last=` argument to new_oid() every place that felt compelled to spread that insanity ;-). Seriously, it served no purpose at all elsewhere, and looks like people just cut 'n pasted in fear.
-
Tim Peters authored
-
- 14 Apr, 2005 1 commit
-
-
Tim Peters authored
-
- 13 Apr, 2005 3 commits
-
-
Tim Peters authored
for Zope3 and Zope trunk development to use.
-
Tim Peters authored
-
Tim Peters authored
-
- 10 Apr, 2005 1 commit
-
-
Tim Peters authored
The test didn't work if run more than once (e.g., via Zope3's test.py's "-N <n>" argument, or via ZODB's test.py's "-L" argument), because the warnings module suppresses warnings after the first a single line. Made the warnings module report repeats of DeprecationWarnings for the duration of the test.
-