One option we've considered is storing information in volatile RAM, then flushing it out to the ZODB every now and then, perhaps by a separate thread to prevent page generation from slowing down. This could work if some loss of data is acceptable (if the server is shut down or crash, some unflushed/unsaved data will be lost), for example information related to the usage of a website: - page counters - clickstream logs - implicitly gathered personalization profiles If you use ZEO you'll get into additional problems of each ZEO client having its own volatile RAM storage that needs to be synced via the ZODB or via some other network protocol. Regards, -- Bjorn -----Original Message----- From: schimcsig marton [mailto:nuon@freemail.hu] Posted At: Wednesday, January 30, 2002 10:18 Posted To: Zope List Conversation: [Zope] Zope's database capability Subject: Re: [Zope] Zope's database capability Hi Zopers, Jim Penny wrote:
Never store things in ZODB that change often (things like page counters are prime examples.)
Are there other solutions for counter-like apps than an RDBMS or the file system? (We don't wanna give Zope file system access for maximum security... ) Do I really have to set up an RDBMS and a table for small, tabular, frequently changing data? Can I do this with non_undo dbs? Is the write process slow because of the undo feature? Thanx, nuon _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )