An error occurred fetching the project authors.
- 16 May, 2010 1 commit
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2117 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 15 May, 2010 1 commit
-
-
Grégory Wisniewski authored
SendPartitionTable packet was sent between Ask and Answer PartitionTable packets, as notifications. In this case, the only purpose of the 'Answer' was to check that the partition table was filled. The 'Ask' allowed also to request a part of the partitions but was not used and redundant with AskPartitionList for neoctl. This commit include the following work: - The partition table is always send in one packet. - The full partition table is always requested with AskPartitionTable - The full partition table is notified with SendPartitionTable - Client node process the answer in the bootstrap handler. - Admin can receive answer *and* notifications for the partition table. - Move the log calls to the pt.py module - Add pt.getRowList() to factorise the code. - Build partition table packets out of the loop when possible - Always load inconditionnaly the partition table in generic pt.py - git-svn-id: https://svn.erp5.org/repos/neo/trunk@2114 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 13 May, 2010 5 commits
-
-
Vincent Pelletier authored
Store deadlocks might happen when the order in which storage nodes receive object data (and hence, grant write lock for those objects) is not consistent among clients. So when a store timeouts, it might be because another transaction got the store lock on this storage and object, while it might wait for locks we got on other storage nodes or objects. In doubt, report a conflict to abort current transaction in hope for the other transaction to succeed. git-svn-id: https://svn.erp5.org/repos/neo/trunk@2109 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
As we don't (and must not, otherwise it would deadlock) take a write lock on a storage node when detecting a conflict, it is possible that multiple conflicts get successively reported for a single object in a single transaction. To solve this, client must tolerate multiple conflict for a single object. The last resolved conflict being sent to all storage nodes, transaction data will be consistent at tpc_finish. - conflict_serial_dict and resolved_conflict_serial_dict become multivalued (sets instead of scalar) - each resolution only resolve conflict with highest serial if greater than previous resolutions for the same object NOTE: this assumes that ("r" being conflict resolution method, "Tn" being the TID on which object is based, and "Cn" being a conflict with transaction n) when r(T0, C1) generates T1 but triggers C2, r(T0, C1) + r(T1, C2) == r(T0, C2) git-svn-id: https://svn.erp5.org/repos/neo/trunk@2108 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2104 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
This allows always checking whether a storage accepted the object for a conflicting serial value, so do it. git-svn-id: https://svn.erp5.org/repos/neo/trunk@2103 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2101 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 28 Apr, 2010 6 commits
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2042 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2041 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2040 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2039 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2038 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2037 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 26 Apr, 2010 2 commits
-
-
Vincent Pelletier authored
There is no need to make a special case in waitStoreResponses if it becomes equivalent to just calling waitResponses. git-svn-id: https://svn.erp5.org/repos/neo/trunk@2029 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
This prevents from having an endless wait on "get" if the last connection from which we were expecting answers got interrupted. Note that this method will not raise any error related to this. git-svn-id: https://svn.erp5.org/repos/neo/trunk@2028 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 23 Apr, 2010 3 commits
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2017 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2016 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
Fixes the following scenario (committing an object): 2 storage nodes: S1 and S2 1 replicas - store in S1 (1) - store in S2 (2) - S1 answers (1) with a conflict - client resolves the conflict, and sends to S1 (3) and S2 (4) - S1 answers (3) with ok - S2 answers (2) with a conflict Old code raises because object store counter was not 0 on an object for which a conflict was reported. New code ignores answers notifying of a conflict if given serial is the already-resolved conflict. Split & extend existing tests. git-svn-id: https://svn.erp5.org/repos/neo/trunk@2015 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 22 Apr, 2010 2 commits
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2010 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@2008 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 07 Apr, 2010 1 commit
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1998 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 30 Mar, 2010 1 commit
-
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1980 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 26 Mar, 2010 2 commits
-
-
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
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1965 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 25 Mar, 2010 1 commit
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1961 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 19 Mar, 2010 3 commits
-
-
Vincent Pelletier authored
It's just broken to do this way (I intended to locally revert that commit, instead of pushing it to the repository... Sorry). git-svn-id: https://svn.erp5.org/repos/neo/trunk@1946 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1945 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1944 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 10 Mar, 2010 1 commit
-
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1934 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 08 Mar, 2010 5 commits
-
-
Grégory Wisniewski authored
Nothing is protected between lock/unlock, only writes to local_var are done and and does not need exclusive access because local_var is thread-specific. git-svn-id: https://svn.erp5.org/repos/neo/trunk@1926 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1925 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1919 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1918 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
Given measure points were used to search for hot spots in client around "store" method. git-svn-id: https://svn.erp5.org/repos/neo/trunk@1911 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
- 05 Mar, 2010 6 commits
-
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1908 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Grégory Wisniewski authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1894 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1892 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1891 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
git-svn-id: https://svn.erp5.org/repos/neo/trunk@1890 71dcc9de-d417-0410-9af5-da40c76e7ee4
-
Vincent Pelletier authored
It is possible to have a transactional undo of object creation without having the object in cache. For some reason, it happens in 6.9GB FileStorage import. git-svn-id: https://svn.erp5.org/repos/neo/trunk@1889 71dcc9de-d417-0410-9af5-da40c76e7ee4
-