Since r2357 "ask" atomically checks connection state before sending, so early
check & locking are not needed here anymore.

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

Breakage introduced in r2632.

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

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

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

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

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

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

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

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

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

If master give us a None uuid, we raise in handler, so we never reach this
statement. self.pt is set when master accepts us, and if we are not accepted
handler raises.

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

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

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

Adding setup files to neotrunk in order to prepare the eggification and
the buildout installation. Each neo's module has its own setup file.

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

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

Still raises if deleted oid is in neither.
There should never be the same oid in both, as per ZODB implementation, so put
assertions to verify this.

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

In order to adapt our code to python standards and buildout functionment,
we had to precise the title '__main__' to launch scripts neotestrunner,
neoadmin, ....

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

Fixes a bug related to the misnamed command variable. Creates a new
temporary variable to stock the path to a command and test it.

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

In order to find neo commands like neoadmin, neomaster, neostorage, ... in
the path of a buildout installation, we must set the path to commands
manually.

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

Bugs corrections with cancelling tabulations and misplaced backslashes.

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

In order to prepare the eggification of the different neo parts, we created a
new neo/lib module, containing all of the main neo's functions. It allows to
make neo a virtual namespace, and so not containing module code anymore.




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

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

- AnswerInformationLocked give ttid instead of tid
- Master transaction manager always use ttid in data structures
- It's no more makes sense to check if the tid is greater than the last
generated as it never comes back from a storage, just check if the ttid is
well known by the transaction manager.
- Rename all tid variable that now hold a ttid
- Transaction manager's queue contains ttids but the corresponding tids are
increasing to keep commit order.
- Adjust tests

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

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

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

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

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

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

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

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

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

With conflict resolution, multiple stores can happen and register more than
once a event with a given key. Avoid crash on a KeyError exception when
removing the key from queued events.

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

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

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

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

Detect if a client requests multiple undo/store based on wrong revisions.
Also, don't try to acquire lock when we know we have it.

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

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

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

This is important for chaining "undo" for a given object in a single
transaction, to allow checking for conflicts.
Also, this means that get_baseTID return value cannot be used to update
cache when undoing, so only update cache when storing a new revision.
Actually, cache was never updated when undoing anyway, as current snapshot
TID was unlikely to exist as a serial for any object, so it would not be
found in cache and update would be a no-op.

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

Also reverts r2533: even if it's true that TIDs have no meaning at that level,
they are a handy way to prioritise a transaction over another, to break lock
cycles (aka deadlocks). This is the "detection" part of the change.
When a storage reports a deadlock, client must store all already-stored
objects again with "unlock" flag set.
Upon receiving those store requests, storage must release locks held by
transaction on those objects, and requeue the store request. If client didn't
hold any lock (initial store was still in queue), drop the second store
request.
This doesn't solve possible deadlocks if ZODB-level sends us objects in a
different order (ex: client 1 sending [OID1, OID2] & client 2 sending
[OID2, OID1]).
There is one important change to r2533's revert, which queues older
transactions and notifies deadlock for younger ones. The original code did it
the other way around, and it looks unfair to old transactions (they will keep
being delayed by younger ones, and will just get older and older).

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