[Zope] Counter and concurrent access

[Paul Everitt]

Luciano is right, but only if you do it by hanging the counter directly 
off the piece of content as a property.  If instead you have a 
persistent subobject, it simply becomes a matter of math.

For instance, let's say it costs 50 bytes to store counter every time it 
increments.  Let's then say you do 10k page views a day, which would be 
a site getting more than a million page views a month.

You're talking about ZODB growth around 500Kb per day, or 15Mb per 
month.  With *any* amount of packing, this shouldn't be too much of a 
problem.

Even better are the approaches previously mentioned where counting goes 
in a central datastructure that queues up increments for an interval, 
then writes them out to some kind of storage.

I don't think you _have_ to leave the ZODB to do counters.  Just don't 
do them as a property or attribute directly attached to the thing you're 
counting.

--Paul

Luciano Ramalho wrote:

> Beware of implementing counters within ZODB! Anytime you change a
> property of a persistent object like a Folder or DTML Document, Zope
> stores a new version of that object in ZODB. This leads to Data.fs
> severe bloat!!! Use a relational database or some other Python-only
> persistence mechanism to store your counter.
> 
> Best regards,
> 
> Luciano
> 
> 
> Yann Lugrin wrote:
> 
>>Hello,
>>
>>I try to create a counter of which I am certain that it sends back in every
>>Call a different result. I should so manage concurent acces on this one.
>>
>>The following method is not valid I have to look for a product which could make
>>works:
>>----
>>ID = context.nextID
>>context.manage_changeProperties( { 'nextID' : ID+1 } )
>>----
>>
>>But products found (FSCounter and to threadSafeCounter) uses the
>>File System to manage the concurrent access on the counter value.
>>
>>I want to use the method described in the article " Advanced ZODB for python
>>Programmers " ( Http://www.zope.org/Documentation/Articles/ZODB2) by creating a
>>product based on the following code:
>>
>>------------
>>class Counter(Persistent):
>>    self.count = 0
>>
>>    def hit(self):
>>        self.count = self.count + 1
>>        return self.count
>>
>>    def _p_resolveConflict(self, oldState, savedState, newState):
>>        # Figure out how each state is different:
>>        savedDiff= savedState['count'] - oldState['count']
>>        newDiff= newState['count']- oldState['count']
>>
>>        # Apply both sets of changes to old state:
>>        return oldState['count'] + savedDiff + newDiff
>>----------
>>
>>Is the class "Persistent" assure the value " self.count " to be not identical in
>>two simultaneous calls of the "hit" method (not identical return value)?
>>
>>--
>>Yann Lugrin
>>yann.lugrin@gmproject.net
>>
>>_______________________________________________
>>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 )
>>
> 
> _______________________________________________
> 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 )
>