百度 金属装饰品中的某些金属沾上汗水，所接触到的皮肤可能出现微红或瘙痒等症状，容易引发接触性皮炎。
Any exceptions raised during the commit() made in afterCall() is badly handled. It seems that the Zope transaction module wants you to abort the transaction after a failed commit(), or at least call begin() again. ZopePublication.handleException() (which we override without delegating to the base class) does transaction.abort() as the first thing.
The failure is raised when the DB policy is removed from the store - which attempts a write to the session, which tries to register the session store with the transaction, which reports that the current transaction is failed.
The end result is that request fails uncleanly, and the user is presented with a "Please try again" page.
There is also probably a bug in the POTemplate:+admin page. As usually IntegrityError that can never succeed are a problem with the view. The publication mechanism can deal with IntegrityError that are caused by concurrent edit, but not with ones that happens because of lack of defensive programming. A UNIQUE-violating update is apparently only flushed at the end of the request when committing. An appserver log from one case of this is attached.
18:18:55 < dpm> so here are the steps to reproduce it for me
18:19:05 < dpm> 1. Go to http://translations.launchpad.net/ubuntu/oneiric/+source/gnome-panel/+pots/gnome-panel-3.0/+admin
18:20:01 < dpm> 2. Change 'Series (Optional)' to 'old-lp-translations/deleted-templates'
18:20:13 < dpm> 3. Change 'Series' to (no value)
18:20:30 < dpm> 4. Press the 'Change' button
18:20:49 < dpm> Then I get the "Sorry, there was a problem connecting to the Launchpad server. ", "Please try again" page
That's a regression as we were able previously to deal with errors happening during commit. (At least, I know for a fact that IntegrityError like that one would be attempted thrice - since IntegrityError are retried - before failing with a standard OOPS page.)
We actually delegate to ZopePublication, but the store disconnection happens before