ODBC and Inserting not committed
Hi, With 2b1, win32, I now find that my Zsql inserts don't commit. They last for as long as the browser is active. I start another browser session after closing the first one down, and they're gone. Updates seem to commit though. Bizarre. ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz
Graham Chiu wrote:
Hi,
With 2b1, win32, I now find that my Zsql inserts don't commit. They last for as long as the browser is active. I start another browser session after closing the first one down, and they're gone.
It's possible, although I have not personally looked at the code, that the ODBC adapter has not been updated to work with the new ZODB3 transaction manager. Try running Zope in single thread mode ('-t 1' on the z2.py command line) and see if the problem persists. If so, then the ODBC driver will probably need to be 'thunked' which is a pretty trivial 10 minute change to the code. Note that thunking a DA has side effects! 'Thunking' means to wrap the Zope DA transaction manager in a thread lock. What this means is that if a DA is thunked, it will work in a multi-threaded Zope, but all ZSQL queries will be serialized at the Zope transaction layer *including queries from other thunked DAs!* This means that all thunked DAs block each other at Zope transacion boundaries (Zope transacion boundaries are usually but not allways, single requests, like an HTTP request). This does not apply to completly thread safe (or, level 3) DAs. To sumarize the levels: Level 1: Not threadsafe, concurrent or thunked. Zope MUST run in single thread mode Level 2: Not concurrent, but threadsafe and thunked. Zope can run in thread mode Level 3: Threadsafe and concurrent. Zope can run in thread mode Going from level 1 to 2 is usualy trivial. That I know of, Gadfly and the soon to be released ZSybaseDA are level 2. Level 3 is much harder, and I believe that DCOracle will probably be the first level 3 DA there is. -Michel
Updates seem to commit though.
Bizarre.
------- Regards, Graham Chiu gchiu<at>compkarori.co.nz
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
In article <379D2E16.D75222E3@digicool.com>, Michel Pelletier <michel@digicool.com> writes
With 2b1, win32, I now find that my Zsql inserts don't commit. They last for as long as the browser is active. I start another browser session after closing the first one down, and they're gone.
It's possible, although I have not personally looked at the code, that the ODBC adapter has not been updated to work with the new ZODB3 transaction manager.
Try running Zope in single thread mode ('-t 1' on the z2.py command line) and see if the problem persists. If so, then the ODBC driver will probably need to be 'thunked' which is a pretty trivial 10 minute change to the code.
I ran it in single thread mode, and the problem has gone away. Actually I just found that updates also did not commit before. Now both commit. Any time frame to seeing the ODBC adapter updated? ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz
In article <58M3aDAI0Wn3Ew48@compkarori.co.nz>, Graham Chiu <anon_emouse@hotmail.com> writes
Try running Zope in single thread mode ('-t 1' on the z2.py command line) and see if the problem persists. If so, then the ODBC driver will probably need to be 'thunked' which is a pretty trivial 10 minute change to the code.
I ran it in single thread mode, and the problem has gone away. Actually I just found that updates also did not commit before. Now both commit.
Oops, spoke too soon. Changes are now saved between browser sessions, but are discarded once Zope2b1 is closed down. ------- Regards, Graham Chiu gchiu<at>compkarori.co.nz
participants (2)
-
Graham Chiu -
Michel Pelletier