Dieter Maurer wrote:
Unless, you begin a new transaction on your load connection after
the write connection was committed,
your load connection will not see the data written over
your write connection.
Good point. After a commit, we *must* poll.
This implies, the read connection must start a new transaction
at least after a "ConflictError" has occured. Otherwise, the
"ConflictError" cannot go away.
Also a good point. All these details will come into play if I attempt
to poll less often.
What I fear is described by the following szenario:
You start a transaction on your load connection "L".
"L" will see the world as it has been at the start of this transaction.
Another transaction "M" modifies object "o".
"L" reads "o", "o" is modified and committed.
As "L" has used "o"'s state before "M"'s modification,
the commit will try to write stale data.
Hopefully, something lets the commit fail -- otherwise,
we have lost a modification.
Yes, RelStorage uses standard ZODB conflict detection: all object
changes must be derived from the most current state of the object in the
database. If any object has been changed by later transactions,
conflict resolution is attempted, and if that fails, the transaction fails.
I noticed another potential problem:
When more than a single storage is involved, transactional
consistency between these storages requires a true two phase
commit.
Only recently, Postgres has started support for two phase commits ("2PC") but
as far as I know Python access libraries do not yet support the
extended API (a few days ago, there has been a discussion on
"[EMAIL PROTECTED]" about a DB-API extension for two phase commit).
Unless, you use your own binding to Postgres 2PC API, "RelStorage"
seems only safe for single storage use.
Actually, RelStorage inherited two phase commit support from PGStorage.
The 2PC API is accessible through psycopg2 if you simply issue the
transaction control statements yourself.
Shane
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
