Commit 02292886 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 0db51eff
...@@ -491,23 +491,25 @@ class ClientStorage(object): ...@@ -491,23 +491,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:
reconnect = 1
else:
reconnect = 0
self.set_server_addr(conn.get_addr())
# If we are upgrading from a read-only fallback connection, # If we are upgrading from a read-only fallback connection,
# we must close the old connection to prevent it from being # we must close the old connection to prevent it from being
# used while the cache is verified against the new connection. # used while the cache is verified against the new connection.
if self._connection is not None:
self._connection.close() self._connection.close()
self._connection = None
self._ready.clear()
reconnect = 1
else:
reconnect = 0
self.set_server_addr(conn.get_addr())
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