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

Add a related test case.

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

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

Keep it enabled by default so tests run with it.

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

This happens from time to time in tests, most probably during shutdown as
it doesn't make tests fail. This will help tracking this bug down.

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

This allows automating tasks right before test fails (for example, dumping
database state) for later inspection.

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

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

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

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

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

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

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

- FinishTransaction -> AskFinishTransaction
- LockInformation -> AskLockInformation

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

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

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

Either the transaction got the load lock for all its objects, or it got it
for none. So instead of having a "try..except" block which either passes
or catches for each iteration, use a simple test.

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

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

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

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

Just being known to the same transaction doesn't propagate isolation
from one connection to another.

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

This uncovered the bug fixed in r1553, and also uncovered a bug in
test_01_EpollEventManager (fixed in this commit).

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

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

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

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

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

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

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

This reverts commit r1630.

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

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

This create an object each time a transaction or object is stored, even if the entry is found in the dictionnary.

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

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

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

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

This ensure it will not reappear in pending state.
Explain why the connection is closed by the master rather than wait for a remote closure.

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

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

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

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

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

If a client node disconnect from storage node right after send 'finishTransaction' to the primary master, then the storage clear it's related information and can not store them later in the database, when notifyUnlockInformation is received from the master.
Here the transaction object got a new attribute '_locked' set when the storage receive the 'lockInformation' from the master, meaning that the client is finish it's transaction.
If locked, the transaction is not cleared when the client disconnect from storage node.

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

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