Do you use this unique ID only as some kind of session ID? If you only
need these IDs during a session (don't have to store them in ZODB), you
can create a thread safe class for managing them and then use an instant
of this class as a module global variable in your product.
AFAIR, this is the way how exUserFolder implements it's usercache. You
can get a clue by examining these files:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/exuserfolder/exUserFold
er/UserCache/UserCache.py?content-type=text%2Fplain&rev=1.16

http://cvs.sourceforge.net/viewcvs.py/*checkout*/exuserfolder/exUserFold
er/exUserFolder.py?content-type=text%2Fplain&rev=1.91

Regards,
Sandor

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ian Beatty
> Sent: Wednesday, March 31, 2004 4:26 PM
> To: [EMAIL PROTECTED]
> Subject: [Zope-dev] Threads, Locks, Volatility, and Angst
> 
> 
> Greetings.
> 
> I'm looking for a little wisdom -- specifically, about thread 
> locks and
> Zope.
> 
> I'm developing a Python-based product. One of the classes 
> needs to hand out
> unique IDs to clients as they connect for the first time. I 
> generate these
> by keeping an index integer in the instance that starts at zero,
> incrementing it by one for every new client, and using the 
> new value for the
> unique ID. In order to prevent race conditions when two 
> clients connect
> almost simultaneously, I have another instance variable in my 
> class that
> holds a threading.lock(). I call acquire() on that lock just 
> before the
> increment-and-report code, and release() just after. So far so good.
> 
> That seemed to work just fine yesterday when I coded it. Then 
> I shut down
> Zope overnight and started it up again today. Now, I cannot 
> create a new
> instance of the class without getting the Zope error 
> "UnpickleableError:
> Cannot pickle <type 'thread.lock'> objects". (I'd swear it was working
> yesterday, though.)
> 
> I thought "Okay, no problem. I'll just make the lock variable 
> volatile,
> since I don't really care whether it persists when Zope shuts 
> down." So I
> renamed the lock to begin with '_v_'. That solves my 
> "UnpickleableError"
> problem nicely. Unfortunately, it introduces a different 
> problem: the code
> that calls acquire() on the lock now throws "AttributeError: 
> 'NoneType'
> object has no attribute 'acquire'". I'm sure I initialize 
> that variable to a
> threading.Lock() in the object's __init__ method. So now I'm 
> worried that
> Zope is doing all kinds of pickling-unpickling activity 
> behind the scenes,
> and anything I have that's volatile can disappear without warning.
> 
> Are there any thread-wise Zopistas out there who can steer me right?
> 
> Thanks,
> 
> ..Ian
> 
> -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
> Dr. Ian Beatty                           [EMAIL PROTECTED]
> Physics Education Research Group              voice: 413.545.9483
> Department of Physics                           fax: 413.545.4884
> Univ. of Massachusetts              AIM: (available upon request)
> Amherst, MA 01003-4525 USA       http://umperg.physics.umass.edu/
> -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --
> 
> 
> 
> _______________________________________________
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
> 


_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to