git-svn-id: https://svn.erp5.org/repos/neo/trunk@2012 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2011 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2010 71dcc9de-d417-0410-9af5-da40c76e7ee4

There are 2 distinct kinds of timeout events:
- an unresponsive node
  This is a connection-level timeout.
  This is handled by the Timeout class, triggering pings and monitoring
  incoming data to decide when remote node is considered dead.
- a "too long" processing from an otherwise responsive node
  This is a per-request timeout.
  This is handled by the HandlerSwitcher class, triggering only
  disconnections when an answer takes too long to arrive (historical
  behaviour, not so useful when exchanging with a single-threaded peer).

Previous implementation mixed both, and had shortcomings (ping would
timeout almost immediately, it was not possible to tell which message
caused a timeout).

Update tests.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2009 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2008 71dcc9de-d417-0410-9af5-da40c76e7ee4

This code appeared obscure upon second read, so I document it.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2007 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2006 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2005 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2004 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2003 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2002 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2001 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2000 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1999 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1998 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1997 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1996 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1995 71dcc9de-d417-0410-9af5-da40c76e7ee4

Typical case:

- Handler H1 is set
- Send request R1
- Request switch to handler H2 (delayed)
- Request switch to handler H3 (delayed)
- Receive answer A1
- H2 must be discarded and H3 applied on the connection

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1994 71dcc9de-d417-0410-9af5-da40c76e7ee4

- Store None values as NULL column values
- Raise KeyError if the configuration entry is not found

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1993 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1992 71dcc9de-d417-0410-9af5-da40c76e7ee4

Remove admin's app.ptid attribute, use pt.load() and pt.update() instead
of copy/paste the code.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1991 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1990 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1989 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1988 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1987 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1986 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1985 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1984 71dcc9de-d417-0410-9af5-da40c76e7ee4

This fix a race condition when switching from recovery to verification
steps where NotifyLastOID packet could be handled by verification handler
instead of initialisation (storage side).

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1983 71dcc9de-d417-0410-9af5-da40c76e7ee4

This packet handler should be dropped but it's break some functional tests,
may be due to a race condition when switching from recovery to verification.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1982 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1981 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1980 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1979 71dcc9de-d417-0410-9af5-da40c76e7ee4

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

OID 0 is a very valid oid. It's often used for the most important object of
the database: the root object. Using 0xffffffffffffffff leaves some space.

TID 0 is a very valid tid, for transactions back in unix year 0... or
ZODB tests. Using 0xffffffffffffffff leaves some space.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1977 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1976 71dcc9de-d417-0410-9af5-da40c76e7ee4

Test case (added):
- Start a cluster with two storages
- Restart the whole cluster except one storage
- Allow recover from existing storage
- The admin crash when getting the new partition table because it doesn't
known the second (down) node.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1975 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1974 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1973 71dcc9de-d417-0410-9af5-da40c76e7ee4