1. 17 Sep, 2008 2 commits
  2. 15 Sep, 2008 1 commit
  3. 11 Sep, 2008 1 commit
  4. 05 Sep, 2008 3 commits
  5. 04 Sep, 2008 2 commits
  6. 27 Aug, 2008 3 commits
  7. 23 Aug, 2008 4 commits
  8. 22 Aug, 2008 4 commits
  9. 04 Aug, 2008 1 commit
  10. 24 Jul, 2008 3 commits
  11. 14 Jul, 2008 7 commits
  12. 08 Jul, 2008 5 commits
    • Jim Fulton's avatar
      Made caches thread safe. In theory, caches are protected by ZEO · d649173c
      Jim Fulton authored
      clients, but ZEO clients haven't provided very good protection,
      leading to cache corruption.  We'll hopefully fix these client issues,
      which cause other problems beside cache corruption, but it seems
      prudent to provide low-level cache protection.
      d649173c
    • Jim Fulton's avatar
      The order of operations seemed odd. If we get a new connection, we · 8195c421
      Jim Fulton authored
      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.
      8195c421
    • Jim Fulton's avatar
      d4161f92
    • Jim Fulton's avatar
      In ClientStorage, There was a flag to record whether a connection is · e5b6e242
      Jim Fulton authored
      read_only. It was set when a connection was tested, before the
      connection was attached t the storage.  This made me wonder if the
      flag and connection could get out of sync.  Because of details of the
      complex connection dance, it appears that the flag will have a usable
      value, almost by accident.  Ironically, if the storage was opened
      read-only, this flag was set to true.  This all seemed very fragile,
      and probably a bug magnet.  I refactored this so the flag is on the
      connection, rather than the storage.  I also arranged that if the
      storage is opened read-only, the flag is True.
      e5b6e242
    • Jim Fulton's avatar
      Updated the mechanism to select test server ports to remove a source · 15d72c07
      Jim Fulton authored
      of intermittent test failures.  In ConnectionTests, a random port was
      selected without checking if it was in use.  testZEO.get_port (moved
      to forker) picked a random port, checking if it was in use, but
      clients actually used that port *and* the following one.  Now check
      that the returned and subsequent ports are free. (Of course, they
      could get used betweed the time they're selected and the time they are
      used by the test. Oh well.
      15d72c07
  13. 28 May, 2008 1 commit
  14. 23 May, 2008 2 commits
  15. 14 May, 2008 1 commit