RE: [Zope] Sharing global data between threads / locking a method
I think that storing an "isMyProcessingStarted" property would not work, because the transaction that modifies the property value would not be committed until the long processing is done, so when the next transaction that reads this value starts (if this happens before the previous one has finished), it would still see the old value. If you are using a single Zope instance, you can try something nasty like : #to read the value : try: test=_isMyProcessingStarted except: test=0 #to write the value : import __builtin__ __builtin__._isMyProcessingStarted=<value> Hope that helps... Pascal -----Message d'origine----- De : zope-bounces+pperegrina=lastminute.com@zope.org [mailto:zope-bounces+pperegrina=lastminute.com@zope.org]De la part de Jonathan Envoyé : lundi 27 juin 2005 17:00 À : Jim Abramson; zope@zope.org; Max M Objet : Re: [Zope] Sharing global data between threads / locking a method ----- Original Message ----- From: "Jim Abramson" <jabramson@wgen.net>
A possible solution: create a property field on the folder where the external methods are stored. Have your external method update this property field when the external method starts and again when it exits. This way you can test whether or not the external method is currently in operation. You could store this property field on a temp_folder for faster performance.
Curious,
- to save variables in this way, must a Folder property be used, or would a class variable set on something that extends Folder work the same?
You can store the property field on/in any zope object that can be accessed via the external method.
- why does temp_folder perform faster for this technique?
'temp_folder' folders are 'temporary' and only exist in memory (objects stored in/on 'temp_folders' are not written to the zodb), therefore are faster to access, but the downside is that when zope is shutdown all temp_folder content is lost. Jonathan _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
----- Original Message ----- From: "Pascal Peregrina" <Pperegrina@lastminute.com>
I think that storing an "isMyProcessingStarted" property would not work, because the transaction that modifies the property value would not be committed until the long processing is done, so when the next transaction that reads this value starts (if this happens before the previous one has finished), it would still see the old value.
Interesting thought... you would have to do a test to see what gets commited and when. I think you are right about the property field on a zope object not getting 'committed' to the zodb until the transaction completes, however I am not sure when changes are made to 'temp_folder' objects as they are not committed to the zodb (ie. do changes to temp_folder objects happen immediately or are temp_folder changes also tied in to the committment machinery)? Some testing would have to be done to confirm this. There is a quick solution though: include the following command in your external method after your code that modifies the 'flag': get_transaction().commit() This will invoke the zope commitment machinery immediately. Jonathan
Jonathan wrote at 2005-6-27 11:33 -0400:
... I am not sure when changes are made to 'temp_folder' objects as they are not committed to the zodb (ie. do changes to temp_folder objects happen immediately or are temp_folder changes also tied in to the committment machinery)?
They are (tied to the commitment machinery). The only difference between a "temp_folder" and a "less temporary" object is its storage. "temp_folder" is backed by a "Temporary Storage" that lives in RAM and disappears when the process dies. Otherwise, it behaves like any persistent object. -- Dieter
participants (3)
-
Dieter Maurer -
Jonathan -
Pascal Peregrina