[Zope-dev] I volunteer to make ConflictError handling "better" if you guys can help me ;-)

[Dieter Maurer]

Chris Withers wrote at 2005-11-24 19:42 +0000:
> ...
>I would really appreciate it if you could dig this out and give me a 
>direct url. If you do, I promise I will see it gets properly merged into 
>the Zope core...

You know that I *never* search for others (I hate searching).

But I can show you the code, we currently use in our Zope version
(which has the improved logging and some other fixes):

            if issubclass(t, ConflictError):
                # First, we need to close the current connection. We'll
                # do this by releasing the hold on it. There should be
                # some sane protocol for this, but for now we'll use
                # brute force:
                global conflict_errors
                conflict_errors = conflict_errors + 1
                method_name = REQUEST.get('PATH_INFO', '')
                err = ('ZODB conflict error at %s: %s'
                       '(%s conflicts since startup at %s)')
                LOG(err % (method_name, str(v), conflict_errors, startup_time),
                    INFO, '')
                LOG('Conflict traceback', BLATHER, '', error=sys.exc_info())
                raise ZPublisher.Retry(t, v, traceback)
            # DM 2005-06-28: work around "lost retry exception logs" problem
            #  (reported by "Malcolm Cleaton" "mailto:malcolm at jamkit.com"
            #  in the mailing list)
            #if t is ZPublisher.Retry: v.reraise()
            if t is ZPublisher.Retry:
                try: v.reraise()
                except: t, v, traceback = sys.exc_info()

This code sits in "Zope2.App.startup.zpublisher_exception_hook".

The improved logging is achieved by including "str(v)" ("v" contains
the exception value) into the log message (it is that easy).


The last part (marked with "DM 2005-06-28") fixes a problem that
your "error_log/standard_error_message" will not see any "ConflictError".

   While it is correct that the "error_log/standard_error_message"
   should not see "ConflictError"s that are retried;
   it should see (and if configured correspondingly
   log) the "ConflictError"s that go out to the user.

With this fix, you do not need special handling (e.g. logging)
of "ConflictError"s that go out to the user.
They can (and should) just be handled as any other exception.

>>>Did the user actually see a ConflictError page?
>> 
>> Usually not.
>
>...which, as I suspect you agree with me, simple isn't a good enough 
>answer ;-)

Add the fix shown above -- and the really problematic
"ConflictError"s (those seen by your customer) are handled the same
way as other exceptions seen by your customer (a good thing!).

> ...
>> I would not be happy: it is about 5 %.
>
>Yeah, me neither, but it would be great to quantify all of this :-)

But, you can't.

   It is very difficult to quantify statistics precisely...

-- 
Dieter