This is a pretty good idea... the default RAM-based storage that is used 
for sessions (TemporaryStorage) tries hard to resist conflicts. It is 
also nonundoing and does its own reference counting, so it needn't be 
packed unless there it contains cyclic datastructures (there is no UI to 
pack the default mounted storage anyway, so the  problem is kind of 
moot).  The TransientObject code (the SESSION object is an instance of a 
TransientObject) can make use of ZODB conflict resolution in many cases.

However, conflicts are still a problem with TemporaryStorage because it 
is a ZODB Storage implementation and it uses the same "optimistic 
concurrency control" as does FileStorage et. al.  But I imagine for most 
applications, the "out of the box" configuration would work just fine 
for things like counters and whatnot.  Someone could probably implement 
a limited-functionality session data storage that did not rely on ZODB 
or any other database that might be even better for this kind of thing.

Romain Slootmaekers wrote:
> Yo,
> I have been following this thread for quite some time now,
> and call me stupid if you must, but why don't you just keep 
> the data in the session and write it all out when the session
> gets cleaned up?
> For the original problem (keeping statistics of site usage)
> this will be more than enough. 
> I did a webmining project using this in 2000 
> (ok, it was jsp and not zope, but the approach is still valid, moreover
> since from 2.5? onwards, you have a built in SESSION object you can use) 
> have fun,
> Sloot. 
> _______________________________________________
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> **  No cross posts or HTML encoding!  **
> (Related lists - 
> )

Chris McDonough                    Zope Corporation   
"Killing hundreds of birds with thousands of stones"

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to