openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miłosz Tylenda <mtyle...@o2.pl>
Subject Re: Streaming BLOB/LOB : who closes the stream?
Date Fri, 10 Apr 2009 15:20:47 GMT
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/
> 

Mime
View raw message