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