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

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

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

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

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

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

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

This makes sure all invalidations about loaded object up to its actual load
have been received by client, and forwarded to ZODB.
This fixes a potential problem of a transaction being able to see objects
committed by another transaction after it started itself.

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

The problem with previous implementation was that each storage locally
decided what undo actually did to data. This causes problems when a
storage doesn't have a complete view of past transaction but accepts write
queries, ie when it replicates.
This implementation reduces the decision to a readable subset of storage
nodes (which are hence not replicating), and then sends that decision to
all storage nodes, hence fixing the issue.
Also, DatabaseManager.storeTransaction now consistently expects object's
value_serial to be packed, not an integer.

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

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

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

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

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

Otherwise, None ends up being put in object cache, which fails.

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

This fixes random failures in old ZODB undo tests, where tpc_vote was not
called before tpc_finish/tpc_abort.

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

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

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

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

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

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

This makes it possible to implement an undo on client side, as a flaw has
been found in it when used in parallel with replication.

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

This was intended to be a raise, but was broken. Anyway, it's not
required for not-committed-yet pack implementation.

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

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

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

tm.storeObject is not supposed to return a callable.

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

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

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

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

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

Credit: Leonardo Rochael Almeida
Indentation of setup.py by me.


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

This prepares NEO's initial eggification.
Credit: Leonardo Rochael Almeida


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

Record is expected to contain the TID of previous transaction which
modified given object. This is not the meaning of 3rd value returned by
_load (the TID of the next transaction modifying object).
So, instead, cache the last TID of each object, until there is no next
transaction modifying them.*
As this can become a memory problem with big number of objects, add a TODO.

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

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

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

Also, make HandlerSwitcher.isPending() return a boolean, to avoid leaking
instance content to foreign code.

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

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

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

There are 2 possibilities when an object is not found:
- the object doesn't exist at all
- the object exists, but nothing matches serial criterion

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

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

r2242 removed the case where we wouldn't be abdle to access the last
version of an object with loadBefore, and its test code is reused here to
check the "not visible" case.
r2250 modified the response in case where an internal error occured.

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