Re: [ZODB-Dev] Shared/DC/ZRDB/TM.py:_register
Vincent Pelletier wrote at 2008-5-22 11:21 +0200: ... BTW, the usual error hook treats conflict error exceptions differently from others, and I guess it was done so because those can happen in TPC. No, the reason is to repeat a transaction that failed due to a ConflictError. -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Shared/DC/ZRDB/TM.py:_register
Le Thursday 22 May 2008 10:40:46, vous avez écrit : Maybe, you search the zope-dev archive to find the thread that convinced us to change the former behaviour (the one you want now again) into the current one? Adding links for possible future reference: https://bugs.launchpad.net/zope2/+bug/142446 First discusses a problem with handling erorr outside of any transaction, suggesting a fix similar to mine, and then later it was agreed that failed transaction should be aborted after error handling (https://bugs.launchpad.net/zope2/+bug/142446/comments/3). The same can apply to __traceback_info__ and __traceback_supplement__ information derived from persistent objects. This information will then reflect the persistent state as it has been when the transaction started and not as it was when the exception occurred. I see. Thanks. And the problem with providing a pointer to such information is the same as having 2 transactions simultaneously started for the same thread, I guess. The ZODB has a notion of doomed transaction. A transaction gets doomed when something happens that can can lead to persistent inconsistencies should the transaction be committed. A failing commit and an unsuccessful reset to a savepoint are example doom reasons. I am not sure whether a ReadConflictError, too, dooms the transaction. BTW, the usual error hook treats conflict error exceptions differently from others, and I guess it was done so because those can happen in TPC. In my case, the problem was triggered by MultipleUndoErrors, which is not specialy handled. I have the feeling that current exception class inheritance scheme is not so good, and that it would be needed to create more abstract exceptions classes to inherit from. For example, an exception class which would instruct publisher to retry transaction and another to instruct it to give up (...and of course abort transaction) as fast as possible. I have no idea about the needed amount of work. -- Vincent Pelletier ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Shared/DC/ZRDB/TM.py:_register
--On 13. Mai 2008 10:36:48 +0200 Vincent Pelletier [EMAIL PROTECTED] wrote: Hi. _register method of TM class in Shared/DC/ZRDB/TM.py hides all exceptions. This makes descendants of this class prone to get stuck in a registered state withtout any possibility of them to get commited. To reproduce the problem: - create a class inheriting from TM, and define a method calling register.Add logs to abort and commit method to track transaction end. - create a default error page which triggers a call to the method created above. (this is equivalent to accessing some database from the error page,for example) Call it twice. Most realistic case is using an instance surviving the transaction (a global, or a persistant object) - tigger an error in TPC (a raise in vote is the most realistic case) and getthe error page to render. The most obvious breakage I could see is whentrying to undo an non-undoable transaction (modify a script twice, undo theoldest without undoing the newest) Here is what happens: - first transaction (the undo in my example) raises in TPC, transaction ismarked as failed - error message gets rendered in the same transaction (that's a ZPublisherbug, but I think the problem root is hiding the failure) - error message tries to register itself to transaction manager: First try gets an exception (hidden in TM._register), but in the processtransaction's _adapters dict was modified. TM subclass instance is notmarked as registered. Second try, now there is no exception raised, because transaction's joinis not called (because of _adapters content). Now the TM subclass instanceis marked as registered, but unknown to transaction (_adapters will not beused to commit). The variant with just one call to TM._register only causes the instance to be commited at next transaction using it. Is there any reason why TM._register is hiding exceptions ? Isn't the right approach for integrating a module with ZODB transactions using a ZODB DataManager? Andreas pgpBTR1J9YUMG.pgp Description: PGP signature ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Shared/DC/ZRDB/TM.py:_register
--On 13. Mai 2008 20:08:15 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Andreas Jung wrote at 2008-5-13 10:44 +0200: ... Is there any reason why TM._register is hiding exceptions ? Isn't the right approach for integrating a module with ZODB transactions using a ZODB DataManager? Shared.DC.ZRDB.TM.TM is the standard Zope[2] way to implement a ZODB DataManager. Nowadays you create a datamanager implementing IDataManager and join it with the current transaction. Shared.DC.ZRDB.TM.TM is pretty much old-old-old-style. Andreas pgpJa88lGWbkd.pgp Description: PGP signature ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Shared/DC/ZRDB/TM.py:_register
Andreas Jung wrote at 2008-5-13 20:19 +0200: ... Shared.DC.ZRDB.TM.TM is the standard Zope[2] way to implement a ZODB DataManager. Nowadays you create a datamanager implementing IDataManager and join it with the current transaction. Shared.DC.ZRDB.TM.TM is pretty much old-old-old-style. Time to change the Zope 2 code base ;-) There, you still find the old way -- and it is used by other Zope 2 components -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
