Quoting Justin Azoff <[EMAIL PROTECTED]>:
The problem I was seeing was similar to this, but not the same. The
stale values were not coming from sqlobject caching at all, but from the
MVCC in postgresql...
Using transactions for all reads will get around this problem, but the
root cause is that autocommit was getting turned off and you would get a
transaction without asking for one.
Doesn't seem like r1578 addresses this (separate autocommit bug, properly
re-setting autocommit before releasing Transaction's connection to the pool.)
In this case, the staleness is because the connection isn't released to the
pool, and is reused implicitly by objects still in Thread A's transaction.
Using trans.commit(close=True) and then trans.begin() (in your Thread A) from
r1537 seems to do it for me in your scenario.
As written today, the "implicitly start a new transaction if you do
anything in
a transaction after commit()" seems to be the intention, although I'm not a
big fan - I would prefer close=True to be the default, releasing the
connection on commit, if you want to keep that connection then you should have
to explicitly say so. But that does mean you have to explicitly begin() if you
want to keep using those objects in the committed trans.
Alternatively, if the motivation is not about keeping the same underlying
connection (shouldn't matter?) but to avoid the begin() call, it seems like
the correct way to keep current behavior while fixing the staleness is to have
commit() look like:
self._connection.commit()
+ self._makeObsolete()
if not close:
- self._makeObsolete()
+ self.begin()
Which for me illustrates the strangeness of this default close=False behavior.
- Luke
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
sqlobject-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
