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?