It was broken since commit 4a4d2e64
("client: optimize by not calling lastTransaction at the end of transactions").

This fixes several unit tests like
neo.tests.zodb.testBasic.BasicTests.check_tid_ordering_w_commit

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

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

testVerificationCommitUnfinishedTransactions was failing randomly depending
on whether the cluster was started before or after the storage initializing
connection with the master.

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

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

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

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

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

Also patch ZODB to fix an invalidation bug.

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

A ConflictError is raised instead.

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

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

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

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

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

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

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

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

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

This fixes a regression introduced by implementation of IMVCCStorage in r2532.
On recent ZODB, this fixes a severe performance issue.
With ZODB 3.4, objects were never invalidated, which was even worse.

This fixes includes compatibility code for ZODB 3.4 so that each connection
has its own NEOStorage instance.
The DB's storage is changed to always consider the last revision of
objects.

IMVCCStorage seems too complicated to me. Connection should be a better
place to implement it (by extending/fixing the 'before' attribute).
So we have decided that NEOStorage stops implementing IMVCCStorage.

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

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

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

Just don't use iterkeys on dictionaries, it's the default iterator anyway.

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

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

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

Connection closure is either wanted by the replication node (-> no log)
or not serious (-> warning).

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

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

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

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

1000 transactions is so small that reports showed significant higher values than
with 10000 transactions.

Repeat 2 times instead of 3, so that tests don't take too much time.

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

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

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

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

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

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

All Partition objects must be updated because all of them may contain an object
of the given transaction, even if the transaction itself is stored in another
storage.

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

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

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

What testRestartWithMissingStorageFastStartup tested was never broken.
It is wanted that the missing storage is not known in this use case.

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

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

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

Similar to r2777 but for transactions instead of objects.

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