On Mon, 2003-02-03 at 14:12, Dieter Maurer wrote:
> Then, we must find another explanation for Andrews observation:
>
> He observed heavily inconsistent (Zope) session data
> when he accessed the session during error handling.
> The problem went away when he did not do that.
>
> @Andrew:
>
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 POSKey
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
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(...)
> > 5ma
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.
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
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 b
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 o
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
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.
--
S
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 transact
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 t
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
>
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 h
14 matches
Mail list logo
