Chris McDonough wrote:
I am +1 on this. I suspect that before committing, though, we should
ask people who make use of Zope's transaction manager in advanced
ways like Phillip Eby.
As I noted in the Collector issue, I believe this change is a good idea
overall. As Chris suggests, we should
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:
This is flawed as error handling is done outside of a transaction.
Excellent analysis. A futher problem is that this could cause dangling
references, and a subsequent POSKeyError, since persistent objects can be
passed from one
Chris McDonough wrote:
I am +1 on this. I suspect that before committing, though, we should
ask people who make use of Zope's transaction manager in advanced ways
like Phillip Eby.
I've spoken to Phillip Eby, and he sees no problem with the approaches
we've discussed.
So, +1 from me.
--
All that's fine by me, and allowing an error handler to have side
effects explicitly is probably a good idea... will anybody volunteer to
do this for 2.7?
- C
On Mon, 2003-02-03 at 03:44, Steve Alexander wrote:
By conincidence I'm implementing something similar for error handling in
Zope 3
Your basic point makes sense, although I'm not entirely clear on how
transaction management is integrated into the Zope application.
Speaking for ZODB alone, I believe we've recommended that people call
get_transaction().abort() if they catch an exception. I can't recall
getting into any nuances
Toby Dickenson schrieb:
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:
This is flawed as error handling is done outside of a transaction.
Excellent analysis. A futher problem is that this could cause dangling
references, and a subsequent POSKeyError, since persistent objects can
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:
Zope's current transaction behaviour is essentially:
1 ## request starts
2 transaction.begin()
3 try:
4object= REQUEST.traverse(...)
5mapply(object,...)
6transaction.commit()
7 except:
8
On Mon, 2003-02-03 at 11:11, Joachim Werner wrote:
We are heavily depending on sessions, so the scenario you are describing
could be our problem.
Are you making a reference to a session (or another persistent object)
in your standard_error_message? If not, this is probably not the
problem.
-
Toby Dickenson wrote at 2003-2-3 17:04 +:
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:
Zope's current transaction behaviour is essentially:
1 ## request starts
2 transaction.begin()
3 try:
4object= REQUEST.traverse(...)
5
Jeremy Hylton wrote at 2003-2-3 10:45 -0500:
...
Note that a new transaction is begin implicitly any time a persistence
object is referenced. So the error handling code does execute in the
context of a transaction.
I know...
It may be that it's just not the
transaction you'd like it
Toby Dickenson wrote at 2003-2-3 10:40 +:
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:
This is flawed as error handling is done outside of a transaction.
Excellent analysis. A futher problem is that this could cause dangling
references, and a subsequent POSKeyError,
Zope's current transaction behaviour is essentially:
## request starts
transaction.begin()
try:
object= REQUEST.traverse(...)
mapply(object,...)
transaction.commit()
except:
transaction.abort()
handle_error()
## request ends
This is flawed as error
I am +1 on this. I suspect that before committing, though, we should
ask people who make use of Zope's transaction manager in advanced ways
like Phillip Eby.
- C
On Sun, 2003-02-02 at 10:40, Dieter Maurer wrote:
The new behaviour would look something like this:
## request starts
13 matches
Mail list logo
