[ZODB-Dev] Deadlock in ZODB/DB.py?

Hi there, the DB.open method makes me wonder how it works (http://svn.zope.org/ ZODB/trunk/src/ZODB/DB.py?rev=69551view=auto) It locks with self._a() and calls self._connectionMap which locks too. I cannot imagine a way this could possibly work. I guess the lock should be released before

Re: [ZODB-Dev] [Enhancement Proposal] Garanteed lifetime for volatile variables

Jim Fulton wrote: - I wonder if an argument could be made than we shouldn't implicitly deactivate an object that has been accessed in a a transaction while the transaction is still running. Would this prevent ZODB from ever promising not to use more than a certain amount of memory? The

Re: [ZODB-Dev] [Enhancement Proposal] Garanteed lifetime for volatile variables

Chris Withers wrote: Jim Fulton wrote: - I wonder if an argument could be made than we shouldn't implicitly deactivate an object that has been accessed in a a transaction while the transaction is still running. Would this prevent ZODB from ever promising not to use more than a certain

Re: [ZODB-Dev] Deadlock in ZODB/DB.py?

[Christian Zagrodnick] the DB.open method makes me wonder how it works (http://svn.zope.org/ ZODB/trunk/src/ZODB/DB.py?rev=69551view=auto) It locks with self._a() and calls self._connectionMap which locks too. I cannot imagine a way this could possibly work. Look at __init__(): x =

Re: [ZODB-Dev] [Enhancement Proposal] Memory size limited Cache

Jim Fulton wrote at 2006-10-6 17:04 -0400: ... Thread-safety is not an issue for read-only data. Yes it is. An object that is read-only from a persistence point of view isn't read-only at the Python level. Okay: thread-safety is not an issue for (truely) read-only data. It is potentially an

Re: [ZODB-Dev] [Enhancement Proposal] Garanteed lifetime for volatile variables

Dieter Maurer wrote: Jim Fulton wrote at 2006-10-6 16:55 -0400: ... As explained in the proposal: We have 3 use cases for volatile attributes: I didn't ask why you use volatile attributes. I asked why _p_sticky needs to be stored on each instance, since it is set at the class level. It

Re: [ZODB-Dev] We need to pay down debt

Jim Fulton wrote at 2006-10-5 08:32 -0400: ... I think this is an area where a lot of volunteers could make contributions. Perhaps we could even schedule some ZODB Doc days, similar bug days, but with a different emphasis. I won't insist that new work should wait for this effort Good!

Re: [ZODB-Dev] We need to pay down debt

Russ Ferriday wrote at 2006-10-5 13:45 +0100: I'll provide some time for this, Jim. I'm no expert on the ZODB, which might be spun as an advantage, and I'm prepared to play a supporting role cleaning up doctests, or helping with doc organization. This means I don't mind gathering spippets

Re: [ZODB-Dev] We need to pay down debt

Jim Fulton wrote at 2006-10-5 08:50 -0400: Russ Ferriday wrote: I'll provide some time for this, Jim. I'm no expert on the ZODB, which might be spun as an advantage, and I'm prepared to play a supporting role cleaning up doctests, or helping with doc organization. This means I don't mind

Re: [ZODB-Dev] [Enhancement Proposal] Memory size limited Cache

Dieter Maurer wrote: Jim Fulton wrote at 2006-10-6 17:04 -0400: ... Or consider object activation and deactivation. If a ghost is shared among multiple threads, then __setstate__ could be called from separate threads. But, why should this be a problem? They would install the same state.

Re: [ZODB-Dev] [Enhancement Proposal] Memory size limited Cache

... |Jim Fulton] Or consider object activation and deactivation. If a ghost is shared among multiple threads, then __setstate__ could be called from separate threads. [Dieter Maurer] But, why should this be a problem? They would install the same state. __setstate__ implementations are