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

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