Something that has happened, and is causing a small amount of alarm, is that a large method that interfaces to external non-transactional systems seems to (on occasion) send their information off to that external system twice, but there's only one matching set of Zope data. As the two writes to the non-transactional system are very close to each other and contain nearly identical data (except for one bit that gets regenerated in the method), and there are conflict INFO reports in the Event Log from around the same time, I'm assuming that a conflict error is happening somewhere in this method and causing the transaction to be retried (if I'm understanding how Conflict Errors work). Zope and the relational databases seem to do things fine with rolling back the data, but the non-transactional systems now have duplicate data that they **absolutely should not have**.
This doesn't happen often, but (as stated), this is a critical operation that needs to be better protected. All other exceptions and bits and pieces in the block of code in question has been tested thoroughly and we have not had any other problems that cause erroneous writes. Is there a way I can protect against Conflict Error retries as well? Is there some sort of Try/Except or Try/Finally I can wrap around the code that won't interfere with the ZODB? Is there any other sort of best-practice here that could help me (and others) who might unknowingly trigger this problem?
I know there are some fixes likely to be in Zope 2.6.2 that may help with the situation, but I'd like to put extra protections around this code regardless of what may be coming in the future.
Thanks in advance, Jeffrey P Shell [EMAIL PROTECTED]
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
