openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignacio Andreu <plunch...@gmail.com>
Subject Re: Streaming BLOB/LOB : who closes the stream?
Date Fri, 10 Apr 2009 15:06:19 GMT
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 <david_jencks@yahoo.com>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message