Chris Withers wrote at 2003-10-29 22:03 +:
Dieter Maurer wrote:
What in the ZODB cache or other ZODB code could be causing _v_ variables to
stick around after they've been set to None in their containing objects?
Nothing.
When you assign None to the _v_variable, then
Dieter Maurer wrote:
What in the ZODB cache or other ZODB code could be causing _v_ variables to
stick around after they've been set to None in their containing objects?
Nothing.
When you assign None to the _v_variable, then this reference will go
away. There may be others, which you did not
Chris Withers wrote at 2003-10-23 18:52 +0100:
...
This is slightly OT but reminded me of something important I need to ask.
ZOracleDA stores its database connections in a _v_ variable on the DA object.
It tries to delete this by setting the _v_ variable to None.
However, a number
Toby Dickenson wrote:
No, we just exclude objects with _v_ attribute from mid-transaction
deactivation. There arent many objects in that category, but they do need
protection.
This is slightly OT but reminded me of something important I need to ask.
ZOracleDA stores its database connections in
On Thu, Jan 11, 2001 at 10:26:18AM +, Chris Withers wrote:
Martijn Pieters wrote:
But because _v_* variables don't get pickled, another thread will never
see them.
Hmm, is there any situation where a single request can be handled by
more than one thread?
Nope.
--
Martijn
