ok it is a java/windows bug that they are not planning to fix:
http://bugs.sun.com/bugdatabase/view_bu … id=4715154
i will rewrite the part so that i don’t use mapped IO (which is causing the problem) but it will be a bit slower in reading.
ok it is a java/windows bug that they are not planning to fix:
http://bugs.sun.com/bugdatabase/view_bu … id=4715154
i will rewrite the part so that i don’t use mapped IO (which is causing the problem) but it will be a bit slower in reading.
Thanks for looking into it. I look forward to having the new file plugin with the issue resolved.
Thanks
John McCann
Johan,
I’m concerned about this as I am recommending that we archive a bunch of paper records dating back to the 1960’s and not available electronically. What I am planning on doing is scanning, adding some locator reference (name, id, perhaps three or four fields in all) and then importing the data and the scan (as a straight picture file) into our Oracle database. When you say it will be a bit slower in reading it sounds like this fix will slow down that process. Or will it only come into play if the ‘delete’ is part of the process? What about on Mac OS X or simply ‘moving’ the file and deleting later - perhaps via some other means? In reading the URL I notice that it is for Java 1.4 and dates back a couple of years - has anything changed for 1.5? The reason I am interested is that I’ll want to do the scanning/importing as quickly as possible and we have thousands of documents to do. So in our case it would be much better if the reading goes as quickly as possible and we take care of the deleting in some other way. Or if we do it on a Mac will we avoid the problem all together?
a bit slower was really a bit slower
i tested the solution that was send over and for example 40 files total 6MB in size is read in and deleted on my laptop within 0.3 seconds..
if there is any delay then it won’t be the reading of the files but the storing of the files in the database.
I should have known I guess that you would be talking in nanoseconds!
Thanks
John