An error occurred fetching the project authors.
  1. 06 Jan, 2011 1 commit
    • Vincent Pelletier's avatar
      Resolve deadlocks detected by storage nodes. · 7fccafeb
      Vincent Pelletier authored
      Also reverts r2533: even if it's true that TIDs have no meaning at that level,
      they are a handy way to prioritise a transaction over another, to break lock
      cycles (aka deadlocks). This is the "detection" part of the change.
      When a storage reports a deadlock, client must store all already-stored
      objects again with "unlock" flag set.
      Upon receiving those store requests, storage must release locks held by
      transaction on those objects, and requeue the store request. If client didn't
      hold any lock (initial store was still in queue), drop the second store
      request.
      This doesn't solve possible deadlocks if ZODB-level sends us objects in a
      different order (ex: client 1 sending [OID1, OID2] & client 2 sending
      [OID2, OID1]).
      There is one important change to r2533's revert, which queues older
      transactions and notifies deadlock for younger ones. The original code did it
      the other way around, and it looks unfair to old transactions (they will keep
      being delayed by younger ones, and will just get older and older).
      
      git-svn-id: https://svn.erp5.org/repos/neo/trunk@2596 71dcc9de-d417-0410-9af5-da40c76e7ee4
      7fccafeb
  2. 29 Oct, 2010 1 commit
  3. 28 Aug, 2010 1 commit
  4. 24 Aug, 2010 1 commit
    • Vincent Pelletier's avatar
      Improve replication SQL queries. · d8a7a177
      Vincent Pelletier authored
      It is more efficient to provide a boundary value than a row count range.
      This fixes replication on partitions with a large number of objects, revisions
      or transactions: query time is now constant where it used to increase, causing
      timeout problems when query duration exceeded ping time + ping timeout (11s
      currently).
      
      git-svn-id: https://svn.erp5.org/repos/neo/trunk@2221 71dcc9de-d417-0410-9af5-da40c76e7ee4
      d8a7a177
  5. 21 Jun, 2010 1 commit
    • Grégory Wisniewski's avatar
      Move stored OIDs check to master side. · 1f629dfc
      Grégory Wisniewski authored
      - The storages no more check the last OID during a store
      - The storages inconditionnaly store the last OID notified by the master
      - The master check during the if a greater oid was used by a client
      - The master always notify the last OID when a pool is generated or if the
      check above is True
      - The master's transaction manager manager the last oid and oid generator
      
      git-svn-id: https://svn.erp5.org/repos/neo/trunk@2180 71dcc9de-d417-0410-9af5-da40c76e7ee4
      1f629dfc
  6. 15 May, 2010 1 commit
  7. 26 Mar, 2010 1 commit
    • Vincent Pelletier's avatar
      Use value_serial for undo support. · 83c02447
      Vincent Pelletier authored
      This mimics what FileStorage uses (file offsets) but in a relational manner.
      This offloads decision of the ability to undo a transaction to storages,
      avoiding 3 data loads for each object in the transaction at client side.
      This also makes Neo refuse to undo transactions where object data would happen
      to be equal between current value and undone value.
      Finally, this is required to make database pack work properly (namely, it
      prevents loosing objects which are orphans at pack TID, but are reachable
      after it thanks to a transactional undo).
      
      Also, extend storage's transaction manager so database adapter can fetch data
      already sent by client in the same transaction, so it can undo multiple
      transactions at once. Requires making object lock re-entrant (done in this
      commit).
      
      git-svn-id: https://svn.erp5.org/repos/neo/trunk@1978 71dcc9de-d417-0410-9af5-da40c76e7ee4
      83c02447
  8. 25 Feb, 2010 1 commit
  9. 23 Feb, 2010 1 commit
  10. 19 Feb, 2010 1 commit
  11. 16 Feb, 2010 1 commit
  12. 12 Feb, 2010 1 commit
  13. 05 Feb, 2010 1 commit
  14. 03 Feb, 2010 1 commit
  15. 02 Feb, 2010 1 commit
  16. 01 Feb, 2010 2 commits
  17. 28 Jan, 2010 1 commit
  18. 13 Jan, 2010 1 commit
  19. 02 Nov, 2009 1 commit
  20. 07 Oct, 2009 1 commit
  21. 05 Oct, 2009 1 commit
  22. 01 Oct, 2009 3 commits
  23. 30 Sep, 2009 1 commit
  24. 29 Sep, 2009 1 commit
  25. 10 Aug, 2009 1 commit
  26. 03 Aug, 2009 1 commit
  27. 31 Jul, 2009 1 commit
  28. 29 Jul, 2009 2 commits
  29. 28 Jul, 2009 3 commits
  30. 23 Jul, 2009 2 commits
  31. 22 Jul, 2009 2 commits
  32. 20 Jul, 2009 1 commit