Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=44ykxS1XobKE7SlUh0xkfmPP+EQPI1fBuSvGJk1RoLa9NXZQeSdvWWVXUEt4DjcgrZuQH1ZCcxeUPVZCKV7OcqqN5OX9uM6mZ4SbCNhC9TqyNV5huyxiAH7lE5JhPWCaWW18a8VQHDnTCNkY04J3S2ClkD64p84wDdIFAqzL//Y=
  ;
Message-Id: <1569129E-1B96-43DF-A4B5-FE9185D4ACE3@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: dev@openjpa.apache.org
In-Reply-To: <49DE2DE8.9040409@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Streaming BLOB/LOB : who closes the stream?
Date: Thu, 9 Apr 2009 17:47:46 -0700
References: <49DE2DE8.9040409@apache.org>


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/
>