Hi Simone, As David said, close the stream is not the business of the framework, if you open the stream you should close it. Maybe we should put a note in the documentation.
Thanks, On Fri, Apr 10, 2009 at 2:47 AM, David Jencks <[email protected]>wrote: > > On Apr 9, 2009, at 10:18 AM, Simone Gianni wrote: > > Hi all, >> I noticed that when using streaming BLOB, after consuming the stream, >> OpenJPA does not close it. This is causing lots of problems to us, cause >> we're working on a system that needs to populate lots of blobs from incoming >> files, submit them to a number of "processors" and then save them back to >> file system storage. Since the FileInputStream we are passing to OpenJPA >> during the "fetch" phase never gets closed, after a few seconds the system >> runs out of resources. >> >> Ignacio, can you confirm this is the case? >> >> Since once the stream is used it is (99% of the times) unusable again, >> OpenJPA should close it in the DBDictionary class, eventually in the method >> that consumes it (it should be copy(InputStream,OutputStream) IIRC). >> >> Documentation says nothing about the need to hold a reference to the >> stream passed to a bean to close it after OpenJPA finished using it, and I >> think it would be quite a pain to close the streams from the application >> layer, cause that would mean keeping a reference to them. In plain english, >> the contract should be something like "If you call the getter and obtain an >> input stream, it's your job to close it, if you call a setter passing an >> input stream, it's OpenJPA job to close it". >> >> I'm testing right now a patch (3 lines) to close it after OpenJPA used it. >> If I'm not missing something and you agree this is a bug, I'll open an issue >> and attach the patch to it to keep track of the problem. >> > > I tend to disagree with you about the design and think whoever opens the > stream should be responsible for closing it. I've repeatedly had to work > around the behavior you are advocating as implemented in IIRC xerces. IIRC > the situation I keep running into is an input stream from a jar entry where > closing the input stream closes the entire jar file. In order to use xerces > we had to wrap the input stream from the jar entry in something that ignores > the close method. This experience has convinced me that something that > reads from a supplied input stream has no business deciding whether to close > it. > > thanks > david jencks > > > >> >> Simone >> >> -- >> Simone Gianni CEO Semeru s.r.l. Apache Committer >> http://www.simonegianni.it/ >> >> > -- Blog: http://plunchete.wordpress.com/ Web Page: http://es.debugmodeon.com/
