Re: [Zope] Question about ZODB and threads
At 04:07 14/10/99 , Pavlos Christoforou wrote:
Hello Zopistas -
Suppose we have a persistent object registered with ZODB which has a list attribute contents. According to ZODB rules we should treat mutable attributes as immutable, but what happens if we are crazy enough to treat them as mutable and do things like:
self.contents.append('crazy')
Had we treated it as immutable we would have done something like:
tmp=self.contents tmp.append('not so crazy') self.contents=tmp
in which case tmp is local to the thread and the last statement triggers ZODB's thread-safe transaction mechanism. However in the first case ZODB is unaware of the modification. This was not a problem before the concurrent ZODB, but I am not sure what would happen if two threads call this function simultaneously. Any ideas? (No it is not a theoretical question. Such a construct can be very useful in many situations where you might want to store data in memory temporarily.)
(I moved this to Zope-Dev). First of all: two threads each get their own copy of the class instance, so you are safe there, they will not interfere with each other. It is at commit time to the DB that things might conflict, but that's where the ZODB has it covered. The fact that the ZODB isn't aware of the change will only cause it not to be committed. Your change will not be visible in any other thread, and will be gone as soon as the object is removed from memory (at least, that's my understanding). You can make the ZODB aware of the changes you made by either changing a mutable on the object, or by setting _p_changed to a true value. Either way the object will be registered with the current transaction and the changes will go though the normal ZODB machinery, including conflict resolution. All this can be found in the ZODB UML model at: http://www.zope.org/Documentation/Developer/Models/ZODB especially, Persistent Objects (top left frame) -> Persistent (bottem left frame) and then read the bottom right frame. Don't you love this setup? =) -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
On Thu, 14 Oct 1999, Martijn Pieters wrote:
(I moved this to Zope-Dev).
Good idea.
All this can be found in the ZODB UML model at:
especially, Persistent Objects (top left frame) -> Persistent (bottem left frame) and then read the bottom right frame. Don't you love this setup? =)
Yes I like it but I miss the occasional: 'hold onto your butts', 'don't try this at home kids' etc to keep my spirit up! I am familiar with the model Martijn, however the whole point of the story is *not* to register the change with the ZODB. It would be nice if I could have a temporary in memory storage, accessible from all the threads and this used to be a simple matter in the pre-concurrent era. Anyway you have answered my question, ie each thread gets a copy of the class instance. Do you think I can get away by creating a class that participates in transactions and where instances of this class modify some class attribute, like: class InMemory: dict_visible_from_all={} def set(self,k,v): self.dict_visible_from_all[k]=v (transaction and garbage collection code ommited) Are class attributes deepcopied too for each thread? (in which case it won't solve my problem). If not would such operations (ie calling an instance set method) be thread safe? I also noticed a module for in memory storage in the ZODB directory, but I am not sure how to combine the regular FileStorage with the in memory one. Thanks Pavlos
On Thu, 14 Oct 1999, Pavlos Christoforou wrote:
I am familiar with the model Martijn, however the whole point of the story is *not* to register the change with the ZODB. It would be nice if I could have a temporary in memory storage, accessible from all the threads and this used to be a simple matter in the pre-concurrent era. Anyway you
Attributes that start with _v_ are volatile, and not stored in the database. If you have a class level _v_ attribute, and modify it, will the object be dirty and committed to the DB? A package level variable will also probably do what you want - if you want instance specific data you would need to use some funky dictionary arrangement protected by semaphores of some kind.
I also noticed a module for in memory storage in the ZODB directory, but I am not sure how to combine the regular FileStorage with the in memory one.
I don't think Zope lets you use multiple stores (yet). ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
On Fri, 15 Oct 1999, Stuart 'Zen' Bishop wrote:
Attributes that start with _v_ are volatile, and not stored in the database. If you have a class level _v_ attribute, and modify it, will the object be dirty and committed to the DB?
No, but I am not sure whether such a change will be visible from the other threads. I think no change would be visible to any other thread unless it is commited.
A package level variable will also probably do what you want - if you want instance specific data you would need to use some funky dictionary arrangement protected by semaphores of some kind.
Yes, I guess you are right. I was trying to avoid dealing with threading programming, and use some Zope trick that already deals with threading issues. The Zen way is to let Jim do the hard work ... Thanks Pavlos
In article <Pine.SOL.4.10.9910150850150.28096-100000@goanna.cs.rmit.edu.au>, Stuart 'Zen' Bishop <zen@cs.rmit.edu.au> wrote:
I also noticed a module for in memory storage in the ZODB directory, but I am not sure how to combine the regular FileStorage with the in memory one.
I don't think Zope lets you use multiple stores (yet).
But a storage can use other storages :-) DemoStorage will layer over another storage. This doesn't do what he wants to accomplish though, I don't think. All changes happen in the Demo storage (and thus are volatile), and the bottom is read-only.
participants (4)
-
Martijn Pieters -
Pavlos Christoforou -
Stuart 'Zen' Bishop -
tsarnaļ¼ endicor.com