An error occurred fetching the project authors.
- 15 Jan, 2003 1 commit
-
-
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.
-
- 14 Jan, 2003 1 commit
-
-
Jeremy Hylton authored
XXX Maybe there should be an option to allow this. A ZEO client can run in disconnected mode, using data from its cache, or in connected mode. Several instance variables are related to whether the client is connected. _server: All method calls are invoked through the server stub. When not connect, set to disconnected_stub an object that raises ClientDisconnected errors. _ready: A threading Event that is set only if _server is set to a real stub. _connection: The current zrpc connection or None. _connection is set as soon as a connection is established, but _server is set only after cache verification has finished and clients can safely use the server. _pending_server holds a server stub while it is being verified. Before this change, a client could start using a connection before verification finished. If verification took a long time, it could even commit a new transaction using a mixing of old and new data.
-
- 07 Jan, 2003 1 commit
-
-
Guido van Rossum authored
variables. Updated docstrings/comments.
-
- 03 Jan, 2003 1 commit
-
-
Jeremy Hylton authored
-
- 20 Dec, 2002 1 commit
-
-
Guido van Rossum authored
self._tbuf was unexpectedly None. The only way this can happen is when the storage is closed (probably by a different thread); close() sets _tbuf to None. It turns out that a TransactionBuffer instance can safely be closed more than once, so there's no need to set _tbuf to None in the close() method.
-
- 13 Dec, 2002 1 commit
-
-
Jeremy Hylton authored
tpc_begin() doesn't return anything anyway. Rename transaction to txn to make lines shorter.
-
- 18 Nov, 2002 1 commit
-
-
Jeremy Hylton authored
XXX Not sure if berkeley still works.
-
- 13 Nov, 2002 1 commit
-
-
Toby Dickenson authored
Merged toby-extension-method-branch - ZEO now asks its storages if there are extra methods that should be proxied by the ClientStorage. This is useful for storages which have features not covered by the standard storage API
-
- 07 Oct, 2002 1 commit
-
-
Guido van Rossum authored
-
- 05 Oct, 2002 1 commit
-
-
Guido van Rossum authored
-
- 04 Oct, 2002 1 commit
-
-
Guido van Rossum authored
It is now easy to provide a subclass of a class that is instantiated, by setting the corresponding hook class variable. E.g. if you subclass ZEOStorage, you should also subclass StorageServer and set StorageServer.ZEOStorageClass to your ZEOStorage subclass.
-
- 01 Oct, 2002 5 commits
-
-
Guido van Rossum authored
-
Guido van Rossum authored
in the docstring that filter should be None. Also change the return value if filter!=None from () to [], to match the type of what it returns in other cases.
-
Jeremy Hylton authored
-
Jeremy Hylton authored
-
Guido van Rossum authored
Also remove unused optional argument 'last' from new_oid() and '_stuff' from load().
-
- 25 Sep, 2002 1 commit
-
-
Barry Warsaw authored
FileStorage/Berkeley storage definition, and undoInfo(), and the storage interface definition.
-
- 23 Sep, 2002 2 commits
-
-
Guido van Rossum authored
ZODB/Connection.py -- the Connection class has a sync() method which calls the sync() method on the storage if it exists.
-
Guido van Rossum authored
XXX This created two unused attributes, self._commit_lock_{acquire,release}. Why? I've gotten rid of them. The test suite succeeds. But they are created by BaseStorage; maybe they play a role in the standard storage API???
-
- 20 Sep, 2002 2 commits
-
-
Guido van Rossum authored
ClientStorage constructor called with both wait=1 and read_only_fallback=1 should return, indicating its readiness, when a read-only connection was made. This is done by calling connect(sync=1). Previously this waited for the ConnectThread to finish, but that thread doesn't finish until it's made a read-write connection, so a different mechanism is needed. I ended up doing a major overhaul of the interfaces between ClientStorage, ConnectionManager, ConnectThread/ConnectWrapper, and even ManagedConnection. Changes: ClientStorage.py: ClientStorage: - testConnection() now returns just the preferred flag; stubs are cheap and I like to have the notifyConnected() signature be the same for clients and servers. - notifyConnected() now takes a connection (to match the signature of this method in StorageServer), and creates a new stub. It also takes care of the reconnect business if the client was already connected, rather than the ClientManager. It stores the connection as self._connection so it can close the previous one. This is also reset by notifyDisconnected(). zrpc/client.py: ConnectionManager: - Changed self.thread_lock into a condition variable. It now also protects self.connection. The condition is notified when self.connection is set to a non-None value in connect_done(); connect(sync=1) waits for it. The self.connected variable is no more; we test "self.connection is not None" instead. - Tried to made close() reentrant. (There's a trick: you can't set self.connection to None, conn.close() ends up calling close_conn() which does this.) - Renamed notify_closed() to close_conn(), for symmetry with the StorageServer API. - Added an is_connected() method so ConnectThread.try_connect() doesn't have to dig inside the manager's guts to find out if the manager is connected (important for the disposition of fallback wrappers). ConnectThread and ConnectWrapper: - Follow above changes in the ClientStorage and ConnectionManager APIs: don't close the manager's connection when reconnecting, but leave that up to notifyConnected(); ConnectWrapper no longer manages the stub. - ConnectWrapper sets self.sock to None once it's created a ManagedConnection -- from there on the connection is is charge of closing the socket. zrpc/connection.py: ManagedServerConnection: - Changed the order in which close() calls things; super_close() should be last. ManagedConnection: - Ditto, and call the manager's close_conn() instead of notify_closed(). tests/testZEO.py: - In checkReconnectSwitch(), we can now open the client storage with wait=1 and read_only_fallback=1.
-
Guido van Rossum authored
constructor signature backwards compatible with ZEO 1. This means adding wait_for_server_on_startup and debug options. wait_for_server_on_startup is an alias for wait, which makes the argument decoding for these two a little tricky. debug is ignored. Also change the default of wait to True, like it was in ZEO 1. This is less likely to screw naive customers.
-
- 19 Sep, 2002 2 commits
-
-
Guido van Rossum authored
-
Guido van Rossum authored
until I added an is_connected() test to testConnection() is solved. After the ConnectThread has switched the client to the new, read-write connection, it closes the read-only connection(s) that it was saving up in case there was no read-write connection. But closing a ManagedConnection calls notify_closed() on the manager, which disconnected the manager and the client from its brand new read-write connection. The mistake here is that this should only be done when closing the manager's current connection! The fix was to add an argument to notify_closed() that passes the connection object being closed; notify_closed() returns without doing a thing when that is not the current connection. I presume this didn't happen on Linux because there the sockets happened to connect in a different order, and there was no read-only connection to close yet (just a socket trying to connect). I'm taking out the previous "fix" to ClientStorage, because that only masked the problem in this relatively simple test case. The problem could still occur when both a read-only and a read-write server are up initially, and the read-only server connects first; once the read-write server connects, the read-write connection is installed, and then the saved read-only connection is closed which would again mistakenly disconnect the read-write connection. Another (related) fix is not to call self.mgr.notify_closed() but to call self.mgr.connection.close() when reconnecting. (Hmm, I wonder if it would make more sense to have an explicit reconnect callback to the manager and the client? Later.)
-
- 18 Sep, 2002 1 commit
-
-
Guido van Rossum authored
The fix is to change testConnection() to only retry the register() call with the read-only flag set when we're not alrady connected. But I don't understand why this fix is needed; I'll keep debugging.
-
- 17 Sep, 2002 1 commit
-
-
Guido van Rossum authored
the _server.new_oids() raising Disconnected or ReadOnlyError). Fixed by adding a try/finally.
-
- 13 Sep, 2002 1 commit
-
-
Guido van Rossum authored
"ClientStorage <pid>", use "ClientStorage:<pid>". Also log a message when a ClientStorage instance is created, showing the pid, the read_only and read_only_fallback parameters, and the storage name. Also log some more things: the retry of the register() call with read_only=1, the notifyConnected call, Also clean up a few comments and docstrings, removing one XXX that seems out of date. Also change the _tpc_cond.wait() method call into a wait(30). That way it is interruptable.
-
- 12 Sep, 2002 1 commit
-
-
Guido van Rossum authored
read-write connection is not available. This refactors ClientStorage.notifyConnected() into two functions, testConnection() and notifyConnected(). testConnection creates the RPC stub and calls the register() method; it returns the stub plus a flag indicating whether this connection was preferred or sub-optimal. If the register() method raises ReadOnlyError, and the new option read_only_fallback was true on the ClientStorage constructor, it is retried with its read_only argument set to 1, and the stub is returned with the sub-optimal flag. notifyConnected() now receives the stub returned by testConnection(), and starts the verification as before. XXX The read_only_fallback feature is not yet tested. XXX More work is needed; when a suboptimal connection is used, the ConnectThread must stay around trying to get a preferred connection, and then it must switch connections on the ClientStorage (how???).
-
- 11 Sep, 2002 1 commit
-
-
Jeremy Hylton authored
-
- 09 Sep, 2002 1 commit
-
-
Jeremy Hylton authored
Different versions of ZODB do different things with the serialnos for abortVersion(). To be safe and avoid giving non-version data with an invalid serialno after an abort version, invalidate the version and non-version data. This hurts cache effectiveness when a version is aborted, but I expect it will have little practical impact.
-
- 08 Sep, 2002 1 commit
-
-
Jeremy Hylton authored
-
- 28 Aug, 2002 3 commits
-
-
Guido van Rossum authored
Change the wire protocol back by providing aliases.
-
Guido van Rossum authored
-
Guido van Rossum authored
Open the cache later to avoid scanning it twice if a connection is made right away. ClientStorage.close() is now idempotent. ClientStorage stores its addr argument as self._addr so the test suite doesn't have to dig it out of the rpc manager to reopen the storage as readonly. Renamed some of the callbacks into the client for clarity: begin -> beginVerify end -> endVerify invalidate -> invalidateVerify Invalidate -> invalidateTrans
-
- 16 Aug, 2002 6 commits
-
-
Jeremy Hylton authored
Use this method to set self._transaction to None and notify another thread.
-
Jeremy Hylton authored
-
Jeremy Hylton authored
Not only can we move the assignment of self._transaction about the timestamp / id initialization, but we can eliminate the test for self._server being None. It will never be None. self._server is the first instance variable initialized by __init__(). It is also assigned to in notifyConnected() and notifyDisconnected(), which do not assign it to None.
-
Tim Peters authored
_basic_init(): repair tpc_cond comments in light of recent changes. tpc_begin: when self._server is None, do tpc_cond.notify() to let other threads waiting for "_transaction is None" to continue.
-
Tim Peters authored
anymore. Tried to fix that. Jeremy, please review the new XXX comments.
-
Barry Warsaw authored
clause.
-
- 14 Aug, 2002 1 commit
-
-
Jeremy Hylton authored
Not sure about this judgement call. It is really convenient to be able to pack a ZEO server, even if it is only accepting read-only connections. Is pack() a write operation? At one level: Yes, it modifies the data.fs. But it doesn't modify current objects, so it isn't the same as calling store(). We can revisit this later if it ends up being a problem for someone.
-