This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'll try to make this concise. Numerous distinct website users need to upload batch files of customer address info and generate labels from them. Right now, the only way I can see to handle this problem is to have them upload each file, then save all the info to the database and then pull it from the database to print labels (and then delete the info from the database since we don't want it around). It's kind of a hassle to have to save it in the database and force the users to delete it from the database. However, I don't know what else to do, because these files can be almost 1 MB, and if I load the list of recipient address objects into some bean's member variable that lasts for the whole session, then as far as I understand it, they could stay in memory indefinitely (until Tomcat was restarted). At least hundreds of users with their own session beans and such could end up using this all on the same day, so how would I be able to get those numerous lists of potentially hundreds of address objects out of memory? I took over this site after a contractor initially designed it, and I'm kind of green on how some of this works. I'm assuming it's set up so that although a user's session beans and other data don't get garbage collected when they close the browser (since the server would have no idea), all of it would be cleared and restarted if the user logged in again. But the user might not log in again for days. It also seems like it could be kind of bad practice in a web app to clear a bean's properties when a user goes to a different part of the site, because they might have multiple browser windows open and be doing several things at once! So is my only recourse to load all the info into the database?
a lot of databases have a notion of temporary tables, so you could continue to use a database but maybe with a temp-table so no one has to maintain it after you're done. the advantages to using a database, as i see them, are that a) the code is already there, and b) it handles some of the tedious work for you (e.g. deduping). having said that, the idea of using a database as just a big bucket always grates for me. one other idea: you could transform the addresses into xml (if not already) and use xslt to merge xml files.