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
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
Hello. Does anyone know why the following script
stalls when I run it in Zope's Management Interface
using the 'Test' command?
context.manage_addProperty(propertyId, propertyValue,
propertyType)
All it does is add a property to a folder. The script
does function properly and doesn't stall when I
on or about, Monday, February 03, 2003, we have reason to believe that Asad Habib wrote
something along the lines of :
> Hello. Does anyone know why the following script
> stalls when I run it in Zope's Management Interface
> using the 'Test' command?
> context.manage_addProperty(propertyId, prop
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
>
> Out of curiosity, Beyond coding XHTML-based ZPTs with tags in the ESI
> namespace, what else is needed in Zope to make this work? Does
> Zope need to
> set an HTTP header for downstream proxies to know that the content of the
> page is supposed to be processed for ESI?
>
> Sean
You won't n
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 o
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
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(...)
> > 5ma
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
On Sat, 2003-02-01 at 12:16, Max M wrote:
> Lennart Regebro wrote:
> > From: "maxm" <[EMAIL PROTECTED]>
> >
> >>Usually a private method is used purely as a mean of implementation. And
> >>should never be called from other objects. This is not the case here, as
> >>the method is clearly a part of
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
We've made another beta release of ZODB 3.1.1 available, including ZEO
2.0.2. This is primarily a bug fix release; see the NEWS.txt file
excerpt below for details. Of particular note are the enabling of the
BTrees-based index for FileStorage and the disabling of the rare
"hosed" state in ZODB.
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:
>
17 matches
Mail list logo
