Hi all! Will that "close it yourself" pattern be possible when using container managed transactions?
Regards, Milosz > 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 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/ >
