Am Dienstag, den 19.07.2005, 00:35 -0700 schrieb David H: ... > Your idea is what I thought of at first - but my Interbase Adapter > doesn't like COMMIT statements (!) and I didn't test it out. But it > seems that would not solve the problem because both ZSQL methods are > embedded in the *same* zope transaction stream, e.g. > > . Submit a page > . call ZSQL1 (part of Zope Tran 100) > . call ZSQL2 (part of Zope Tran 100) <--- this depends on zSqL1 > being executed but the transaction has not been executed yet, its > pending. > . Display a page > . *now* Zope commits (executes all calls - which is too late in this > case). > > When ZSQL2 is called ZSQL1's results are not yet executed into my RDMS > and therefore ZSQL2 cannot see whatever ZSQL1 did. (COMMITs not > with-standing).
Stop. Should Interbase here behave different? Its actually required that a database makes changes visible to all queries in the _same transaction_. It depends on Transaction Isolation Level if you see further changes, e.g. if your Database supports "read committed" - this means you would see data changed by _other transactions_ that started _after your transaction_. > Its understandable that Zope might wait between page presentations to > transact all changes until all succeed ( an exception aborts the > transaction). Its just in some cases they can't all succeed until > some are transacted. Thats weird. I'd like to see the model you are referring to here. Are you perhaps playing with after-commit triggers? _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
