Re: [mv] 15 orders missing

[mikeh@minivend.com]

Quoting Kyle Hayes (kyle540@quicknet.net):
> 
> On Wed, 06 Oct 1999, you wrote:
> > ******    message to minivend-users from "Tech Mail" <tech@khouse.org>     ******
> > The tracking.asc and the backend.asc are missing those orders also, and no
> > email was sent for them.  I did find a trace of the records in the
> > transactions.txt file, and an affiliates file which I manually write to when
> > an order is put through.  I don't have all the order information in either
> > of those files, so I still can't complete the orders.  From the limited data
> > I could find, it looks like there were only about 8 orders made, and some of
> > them had duplicate orders. (I think they KNEW it wasn't working, and were
> > trying again).
> > 
> > None of the 'standard' minivend tracking methods worked though, not the
> > backend.asc, not the tracking.asc, and not the email.
> > 
> > This is a Bad Thing(TM).  I'm going to open a new store soon, and on that
> > one I'm planning on manually saving the data to backup files, because
> > something like this needs to be recoverable!
> 
> Hmm, when I looked at the "simple" demo, I had a gut feeling that it would
> be possible to have the system die in such a way that orders were not
> recorded.  That was partially what motivated me to move nearly all my data
> handling to SQL.  I also changed the way that orders were handled in the
> checkout profile of the checkout page. 
> 

It's pretty hard, but it can be done. Usual reason is running out of
disk space; there is not much I can do there. The best thing to do is
keep session file space, database file space, and tracking files on
different partitions.

Many ISPs are very tricky about clearing no-space errors and not
letting anyone know, so having space when you discover the problem
is not necessarily an indicator.
 
> But, I never did.  So, I am not sure if that tag works.  The idea was to
> see what happened to the state of the order at various points.  I am not
> even sure if that tag will actually kill the page.
> 
> I did finally prove to myself that the checkout profile code seems to be
> executed more or less completely regardless of whether the checks
> succeeded or not.  I have [sql] tags all over and they _all_ are always
> executed regardless of where they are in the profile.  It took a little
> while to figure that one out...
> 
> Losing orders is bad.  Losing them after you have charged the customer's
> credit card is Really Bad(tm).

If you use CyberCash, that should be hard too.

If you find yourself losing orders, then do this just before running
expire:

  bin/dump -c yourcatalog | gzip -c | sessions.`date '+%Y%m%d%H%M'`.gz

That will keep the raw sessions in a file for later reconstructions
if you have problems. Again, if you have run out of disk space
then there is not much that can be done.

Catalogs I have run have now taken about a million orders without
losing one -- except to out-of-disk-space errors. Even then, if your
mail is on a different partition there should be a mailed report.

If no one has ever mentioned this before, One Big Partition is bad
boogie on a production system. Yet I see it done all the time.

-- 
Mike Heins                          http://www.minivend.com/  ___ 
                                    Internet Robotics        |_ _|____
                                    131 Willow Lane, Floor 2  | ||  _ \
It's a little-known fact            Oxford, OH  45056         | || |_) |
that the Y1K problem caused         <mikeh@minivend.com>     |___|  _ <
the Dark Ages. -- unknown           513.523.7621 FAX 7501        |_| \_\