Instead of saving PDF files to the server and zipping them, what I would do is:
If it's only one record (ergo, one PDF), I'd create the binary and use CFHEADER and CFCONTENT to stream it to the browser; that way you won't have to save it to the server HD -OR- worry about deleting it, afterwards.
If there will be multiple PDFs (ergo, up to 20 records selected), I'd create the binaries in a loop, saving each to a different variable, then do a readbinary() in another loop, using CFZIP to create the ZIP file and email it (again, not saving to server HD), using CFMAILPARAM to attach the ZIP to the email.
Yeah, that's exactly what I do with single records, and it works great. But with multiple records, I end up with leftover PDFs.
I'll have to research that readbinary() thing. I've never used that before, so I wouldn't know where to start!
I wonder what the memory impact of holding 20 PDFs in memory would be? How about when handling multiple simultaneous requests (# of requests X PDF memory req'd X 20)?
That's a good question, but this data is so dry, it would probably be someone malicious doing it rather than actual users. FWIW these PDFs are approximately 25kb each.
Tiny enough, then, even if 1000 users all requested 20 records at the same time.
But the readbinary() function is necessary (at least the way I do things) for streaming via CFHEADER and CFCONTENT directly to the browser without saving to the HD. You should be able to do the same thing with multiple PDFs, but instead of streaming the PDF to the browser, you should be able to "stream" it to a ZIP file, then stream the ZIP file (or email it).