- 17 Jan, 2003 20 commits
-
-
Fred Drake authored
-
Fred Drake authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Fred Drake authored
-
Jeremy Hylton authored
-
Guido van Rossum authored
-
Fred Drake authored
-
Fred Drake authored
-
Jeremy Hylton authored
Closes SF bug #659068.
-
Jeremy Hylton authored
-
Guido van Rossum authored
-
Shane Hathaway authored
This change adds a new method, setLocalTransaction(), to the Connection class. ZODB applications can call this method to bind transactions to connections rather than threads. This is especially useful for GUI applications, which often have only one thread but multiple independent activities within that thread (generally one per window). Thanks to Christian Reis for championing this feature. Applications that take advantage of this feature should not use the get_transaction() function. Until now, ZODB itself sometimes assumed get_transaction() was the only way to get the transaction. Minor corrections have been added. The ZODB test suite, on the other hand, can continue to use get_transaction(), since it is free to assume that transactions are bound to threads.
-
Tim Peters authored
+ Transaction T1 deletes some of the keys in bucket B, but not all of the keys. + Transaction T2 deletes (exactly) the keys in B that aren't deleted by T1. The version of B each transaction sees is then non-empty, but conflict resolution creates an empty bucket. However, conflict resolution doesn't have enough info to unlink an empty bucket from its containing BTree correctly. The result is that an empty bucket is left in the BTree, which violates a BTree invariant. The most probable symptom is a segfault, when later & unrelated code tries to access this bucket: an empty bucket has NULL pointers where the vectors of keys and values should be, and accessing code tries to dereference the NULL pointers. I don't know that this error has been seen in real life. It was provoked by a randomized multithreaded simulation program that was trying to provoke errors. This error was provoked frequently by that program; no other kinds of errors have come out of it.
-
Jeremy Hylton authored
Fix likely bug where calling tpc_abort() after a client disconnected did not properly clear the client's internal state about the transaction. The change means that tpc_abort() will never raise a ClientDisconnected error, even when disconnected. Added a new test that sort-of covers this case and deleted another that was testing, in part, that you did get a ClientDisconnected error.
-
Guido van Rossum authored
-
Guido van Rossum authored
run from Daemon.
-
Guido van Rossum authored
-
Guido van Rossum authored
-
Guido van Rossum authored
-
- 16 Jan, 2003 9 commits
-
-
Tim Peters authored
Zope3/ZODB4. Many test fixes from Jeremy (in particular, most of the tests weren't getting run), and new tests from Tim. Note that the new testEmptyBucketConflict() actually shows that a particular rare case of conflict resolution doesn't work correctly now. A fix for that comes next, along with reversing the sense of this new test.
-
Fred Drake authored
repitition and no magical guessing of type names in the datatypes.
-
Fred Drake authored
-
Fred Drake authored
language.
-
Fred Drake authored
-
Fred Drake authored
-
Fred Drake authored
- minor markup changes
-
Fred Drake authored
component provided with zLOG.
-
Fred Drake authored
- add at least something of a test for the datatype
-
- 15 Jan, 2003 8 commits
-
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Jeremy Hylton authored
Handing off to Barry.
-
Jeremy Hylton authored
-
Jeremy Hylton authored
ZEO.Exceptions.ClientDisconnected will always be raised when a client is disconnected. There's also a subclass of this exception in ZEO.zrpc.error so that it's possible to distinguish whether the error occurred in the RPC layer or at the storage layer.
-
Fred Drake authored
-
Jeremy Hylton authored
If the client isn't connected at all, sync() returns quickly and the test fails because it doesn't wait long enough for the client.
-
Fred Drake authored
- convert hostnames to lower case
-
- 14 Jan, 2003 3 commits
-
-
Tim Peters authored
-
Jeremy Hylton authored
XXX Don't expect port 9 to do anything on any machine.
-
Tim Peters authored
is check.check(btree), which performs value-based sanity checks on a BTree (or TreeSet) that the btree._check() method doesn't do. The new checks include that all the bucket keys are in sorted order, and that all the keys within each bucket, and within each internal BTree node, lie within the range necessary for that node. That last is a subtle invariant that can't be checked locally: it requires propagating range info down the tree, and modifying it for each child and each level. This *should* catch any BTree B for which iterating over the keys yields a key K for which B.has_key(K) returns false. Another function check.display(btree) prints the internal structure of a BTree (or TreeSet, Bucket, or Set) to stdout. If check.check(B) ever complains, a clearer picture of the damage can be gotten by staring at check.display(B)'s output. Also beefed up the regular BTree tests by calling check.check() in key places. No surprises (the tests still pass).
-