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  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to