Using A BlockingQueue With A Servlet To Persist Objects

First, this may be a stupid question, but I'm hoping someone will tell me so, and why. I also apologize if my explanation of what/why is lacking.

I am using a servlet to upload a HUGE (247MB) file, which is pipe (|) delineated. I grab about 5 of 20 fields, create an object, then add it to a list. Once this is done, I pass the the list to an OpenJPA transactional method called persistList().

This would be okay, except for the size of the file. It's taking forever, so I'm looking for a way to improve it. An idea I had was to use a BlockingQueue in conjunction with the per开发者_开发知识库sist/persistList method in a new thread. Unfortunately, my skills in java concurrency are a bit weak.

Does what I want to do make sense? If so, has anyone done anything like it before?

Servlets should respond to requests within a short amount of time. In this case, the persist of the file contents needs to be an asynchronous job, so:

1. The servlet should respond with some text about the upload job, expected time to complete or something like that.
2. The uploaded content should be written to some temp space in binary form, rather than keeping it all in memory. This is the usual way the multi-part post libraries to their work.
3. You should have a separate service that blocks on a queue of pending jobs. Once it gets a job, it processes it.
4. The 'job' is simply some handle to the temporary file that was written when the upload happened... and any metadata like who uploaded it, job id, etc.
5. The persisting service needs to upload a large number of rows, but make it appear 'atomic', either model the intermediate state as part of the table model(s), or write to temp spaces.
6. If you are writing to temp tables, and then copying all the content to the live table, remember to have enough log space and temp space at the database level.
7. If you have a full J2EE stack, consider modelling the job queue as a JMS queue, so recovery makes sense. Once again, remember to have proper XA boundaries, so all the row persists fall within an outer transaction.
8. Finally, consider also having a status check API and/or UI, where you can determine the state of any particular upload job: Pending/Processing/Completed.