[Zope] Storing an object in RAM during Zope's up-time

Hung Jung Lu hungjunglu@hotmail.com
Sat, 08 Apr 2000 15:14:34 PDT


--- In zope@egroups.com, "Li Dongfeng" <ldf@s...>  wrote:
>I'm afraid that the only way to keep an object in RAM
>but not as a percistent object is to define the variable
>in a product's global space.

Thanks for answering. There are several ways to implement
Zope up-time variables. But I just find it interesting that
so few people has looked into my message. :) (Except you
and Pavlos.) Using a product is an overkill. You can use
any Python module. Since Digicool has the Globals.py module,
we might as well use that one. That seems a nice place,
better than using Python built-in modules. (If you really
want to, you can even use the __builtins__ module instead
of the Globals module, but I think that's a bit too drastic
and too Perl-ish.)

As the good and nice person that I am [heh heh :)], I include
actual code so other people can play a bit, too.

Implement an external method getMyVar() inside myExternal.py:

----------------------------------------
import Globals

def getMyVar(self):
    if not hasattr(Globals, 'myVar'):
        Globals.myVar = 0
    Globals.myVar = Globals.myVar + 1
    return Globals.myVar
----------------------------------------

Voila, there you have a non-persistent variable that is:
(1) Global to all threads, and
(2) Has a lifetime equal to Zope's uptime.

You can play around with different browser sessions and
also reboot the Zope server to verify these features.

---------------------------------------------------------

You might ask thread safety, and I would say this is
a big issue. I haven't looked into Python threads lately,
but I seem to recall that Python is borrowing Java's
thread model... which almost makes me want to scream.
When JDK 1.0 came out, I couldn't believe they let a
total novice implement the thread features... Sure
enough, most of the JDK 1.0 thread feature were quickly
scrapped and the thread model in JDK 1.1 were better,
but equally stupid because at no time are you guaranteed
exclusive time-slice in a line of code, which in practice
means you have to rely on primitive locking mechanisms
that send you into deadlock minefields whereever you go.

Jave doesn't allow exclusive time-slice (or a global lock)
due to security concerns. But this makes thread programming
really painful. Hopefully Python doesn't repeat the same
mistake of Java. We really really need exclusive time-slice
at least for some of the basic Python operations. Funny thing
is that thread programming has been around town since a long
time ago, but I don't understand why they let all these
grandious novices dictate and screw up everything. :)

------------------------------------------------------------

In short, keep in Globals only those variables that you
read a lot but write just a little. :) Sorry for digressing
so much, but a bad Java experience haunts me a lifetime. :)

regards,

Hung Jung

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com