Commit 8195c421 authored by Jim Fulton's avatar Jim Fulton

The order of operations seemed odd. If we get a new connection, we

should close the old connection, and mark ourselves dissconnected --
or so it seems. :)  I'm chasing connection-invalidation bugs and this
rearrangement makes the logic seem a bit simpler to me and sets the
stage for a later fix for the invalidation problems.
parent d4161f92
...@@ -488,23 +488,25 @@ class ClientStorage(object): ...@@ -488,23 +488,25 @@ class ClientStorage(object):
# this method before it was stopped. # this method before it was stopped.
return return
# invalidate our db cache
if self._db is not None:
self._db.invalidateCache()
if self._connection is not None: if self._connection is not None:
# If we are upgrading from a read-only fallback connection,
# we must close the old connection to prevent it from being
# used while the cache is verified against the new connection.
self._connection.close()
self._connection = None
self._ready.clear()
reconnect = 1 reconnect = 1
else: else:
reconnect = 0 reconnect = 0
self.set_server_addr(conn.get_addr())
# If we are upgrading from a read-only fallback connection, self.set_server_addr(conn.get_addr())
# we must close the old connection to prevent it from being
# used while the cache is verified against the new connection.
if self._connection is not None:
self._connection.close()
self._connection = conn self._connection = conn
# invalidate our db cache
if self._db is not None:
self._db.invalidateCache()
if reconnect: if reconnect:
log2("Reconnected to storage: %s" % self._server_addr) log2("Reconnected to storage: %s" % self._server_addr)
else: else:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment