[Zope] Double and Triple Posts
Chris McDonough
chrism at plope.com
Thu Mar 17 15:28:48 EST 2005
Hi Andy,
On Thu, 2005-03-17 at 14:10, Andy Yates wrote:
> When a user comes to the main page on my site 100+ values are loaded
> from a MySQL db and are stored in the SESSION object. These values are
> used to customize everything from text to images on the site. So, there
> are tons of reads and writes to the SESSION object going on all the
> time.
>
> The only problem I've seen is when I am sending email (multiple emails)
This can be solved by using MailDropHost as a drop-in replacement for
MailHost (assuming you use MailHost to send mail, that is; otherwise you
need to do a bunch of work ;-).
http://www.dataflake.org/software/maildrophost/
> ,
> processing credit cards (double,triple billing)
I've solved this one in the past by storing a dictionary with the
"customer id" of the CC transaction as a key and the time of the last
send of that customer id as the value in a module-level global within
Python code and checking the time for sanity before I try to send a CC
auth request (if the customer id exists in the dict and its value is,
say, less than 60 seconds ago, don't send another). This is a hack but
it works.
> , and inserts into the db
> (duplicate inserts, key violations).
Use a transactional database for this (the only one I really know of
that isn't "by default" is MySQL although it can also use transactional
tables if you tell it to).
> 1. Is using the session object like this just a bad approach in
> general?
Not particularly unless it's causing the site to be slow or act
inappropriately.
> 2. In the critical places where retries cause a problem can I just
> avoid reads and writes to session object? Will this prevent conflicts
> and the retries they cause?
Minimizing the number of session accesses will almost always result in
fewer conflicts. Tweaking the session-resolution-seconds might get you
what you need too. There is another undocumented option to turn of
"inband housekeeping" within the Transience module that would probably
help reduce the number of conflict errors. If you're so inclined, you
could take a look at that and enable it. Your "old" session data won't
be automatically cleaned up, you'll need to do it every so often from a
separate process.
> 3. Is there some other sessioning engine that can be used?
Probably, although I don't know of any that are maintained currently.
Note that you can get rid of all conflicts that are session-related and
*still* get conflicts (for ZODB writes *and* reads), so it's best to
make your apps conflict-resistant by maybe using the advice above,
regardless of what decision you make wrt sessioning.
- C
More information about the Zope
mailing list