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

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

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

Also, fix associated unit test, which did not detect this error because
tested storage was not assigned any partition.

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

This way, when called from "ask", displayed timestamp will be closer to
packet's timeout base timestamp.

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

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

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

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

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

This solve a race condition where the client's thread poll triggers
connection(Lost|Failed) before a call to ask(). In that case a answer was
registered as expected and never cancelled, which lead to a frozen client.

- Split _connectToPrimaryNode
- Move ConnectionClosed at generic level

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

This is required to export data from NEO as done by FileStorage.

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

Same work was done in common and master specific partition table.

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

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

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

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

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

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

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

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

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

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

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

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

This change was accidentally committed, and turns out to be incorrect
(3.4.4 tests fail).

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

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

old = 3.4.4 (Zope 2.8.x)
new = 3.10.0b5 (ZODB svn trunk)

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

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

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

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

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

This fixes a potential bug triggered by a storage disconnecting while this
loop would be running, expecting answers from that storage: this would
prevent this loop from ever exiting.

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

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

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

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

Maybe we could implement our own daemon system someday, but it's not high
priority enough to even be in the TODO list.

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

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

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

This fixes problems in multi-database setups (ie. ZODB and other
databases).
For example, imagine a transaction stores an object in ZODB and its
identifier in a relational database.
Then, another process connected to the same databases and polling the
relational database find the new entry, and tried to load the object from
ZODB.
If the second node didn't process invalidation sent by initial transaction
when it starts its transaction, second client would not be able to see that
object, which should not happen (inter-database inconsistency).

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

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

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