[Zope] mysql auto_increment adding numbers on its own

[Ron Bickers]

> -----Original Message-----
> From: Martijn Pieters [mailto:mj@zope.com]

> Sounds like you are bitten by the fact that MySQL is by default not
> transactional; my guess is that the request is conflicting somewhere, or
> maybe you mail server is raising an error, and the transaction is
> aborted or
> retried (the latter in case of a conflict). MySQL will not roll back the
> transaction at that moment, while the email hasn't been sent yet.

I figured maybe something like that.

Looking at the timestamp of the last two empty MySQL records, they
correspond conspicuously with the session logging information I just
implemented to debug my disappearing carts:

2001-10-02T21:01:19 INFO(0) Session START new token pyid 147139568 sid
19270093Az-6bVJDKrM ip 65.100.181.192
2001-10-02T21:01:19 INFO(0) Session CALL (add [get]) new token pyid
142775672 sid 19270093Az-6bVJDKrM len 0 cart None
2001-10-02T21:01:19 INFO(0) Session CALL (add [set]) new token pyid
147428688 sid 19270093Az-6bVJDKrM len 0 cart None
2001-10-02T21:01:20 INFO(0) Session CALL (Items [get]) pyid 150552544 sid
19270093Az-6bVJDKrM len 1 cart 1
2001-10-02T21:02:17 INFO(0) Session CALL (checkout [get]) pyid 147444240 sid
19270093Az-6bVJDKrM len 1 cart 1
2001-10-02T21:04:20 INFO(0) Session CALL (gatherCheckout [set]) pyid
147436552 sid 19270093Az-6bVJDKrM len 1 cart 1
2001-10-02T21:04:21 INFO(0) Session CALL (verify [get]) pyid 145239704 sid
19270093Az-6bVJDKrM len 2 cart 1
2001-10-02T21:04:21 INFO(0) Session CALL (Items [get]) pyid 145921552 sid
19270093Az-6bVJDKrM len 2 cart 1
2001-10-02T21:04:49 INFO(0) Session CALL (Items [get]) pyid 145921552 sid
19270093Az-6bVJDKrM len 2 cart 1
2001-10-02T21:04:49 INFO(0) Session CALL (Items [get]) pyid 146880720 sid
19270093Az-6bVJDKrM len 2 cart 1
2001-10-02T21:04:50 INFO(0) Session CALL (sendOrder [invalidate]) pyid
145792704 sid 19270093Az-6bVJDKrM len 2 cart 1
2001-10-02T21:04:50 INFO(0) Session END sid 19270093Az-6bVJDKrM
2001-10-02T21:05:09 INFO(0) Session START pyid 152529584 sid
19270093Az-6bVJDKrM ip 65.100.181.192
2001-10-02T21:05:13 INFO(0) Session START pyid 148488176 sid
19270093Az-6bVJDKrM ip 65.100.181.192

It's the last two entries that have the same timestamp as two empty records
in the MySQL database.  There are no conflict log entires in the stupid log.
The 'Session END' entry above has the same timestamp as the successfully
stored and e-mailed order.  The only thing the 'sendOrder' python script
does after invalidate() is RESPONSE.redirect to another page.  It seems that
if it made it that far, a simple RESPONSE.redirect wouldn't cause any
conflicts.  Does this make sense?

Is there a more reliable way to produce a sequence of numbers with less
(zero?) risk of skipping or duplicate numbers?
_______________________

Ron Bickers
Logic Etc, Inc.