Yes, you should split the db activity into sensible transactions, since information about how to roll back is being stored somewhere (though some DBs may not have a problem with this.
You've added a whole new dimension when you say that this data is not, in fact, a local file that you are reading, but a network request. There are many more things between you and the data source that could have trouble with the large data size. I suspect that the most likely is that the server limits the time allowed for the request to complete. Hopefully a server with such a limit provides for restarting the transfer from other than the beginning.
I'm sorry, but I don't have the spare cycles to debug this for you. Try instrumenting things to confirm whether it is a read on the source that is hanging or something else. Since it's hard to get data from a hung process, this requires some imagination. You could write to a file an indication of the point in the code when you are about to read the source, when the source completes, when you are about to talk to the database, when that completes, etc., but note that you must close the file after each write (and open it anew before the next) since otherwise the write may be buffered in the process when it hangs. All those opens and closes will be slow, so if you feel adventurous, a write to a piece of shared memory, shared with a monitoring process, might be better.
If you find something other than the read on the source not returning, write again and I, or someone else, with think with you some more.