A solution that I've employed in the past is to keep the counters in RAM (perhaps in a dict stored as a module global keyed by object path) and write the values that have changed persistently every 5-10 minutes.
The drawback to this is that you can loose some counts if the server goes down, plus the count won't be accurate across ZEO app servers sharing the same storage (but they'll be close). I generally deal with this by reading the commited values rather than the volatile ones. -Casey On Tuesday 05 November 2002 03:55 pm, Brian R Brinegar wrote: > Hello, > > We've had requests from several of our users for the ability to have a > drop in page counter within zope. However creating a page counter python > script which increments some value in zope will bloat the ZODB. > > Solutions exist where values are stored on the file system or in a > database. Unfortunately our users don't have file system access and it is > unacceptable to expect them to request a database account and setup > database connections and methods just to create a page counter. > > I would like to create a Page Counter product that doesn't bloat. If a > product is created that doesn't subclass History or UndoSupport does it > still bloat? > > Zope is transactional, but products like ZLDAPConnection have the ability > to be "non-transactional" what does this mean? Could I use this in my > counter? > > -Brian _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )