Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 05 Jul 2006 09:08:43 +0200
From: John Embretsen <John.Embretsen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-1471) Implement layer B streaming for
 new
 methods defined in JDBC4.0
In-reply-to: <44AA9943.5020508@amberpoint.com>
Sender: John.Embretsen@Sun.COM
To: derby-dev@db.apache.org
Reply-to: derby-dev@db.apache.org
Message-id: <44AB657B.6070609@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References: <8441619.1152026370681.JavaMail.jira@brutus>
 <44AA9943.5020508@amberpoint.com>
User-Agent: Thunderbird 1.5.0.2 (X11/20060427)

Bryan Pendleton wrote:
>  > Kristian Waagan commented on DERBY-1471:
>  > ----------------------------------------
>  >
>  > The approach is to exhaust the application stream and copy it into
>  > memory to determine the length. If the data is too big to fit in memory,
>  > the client will fail with an out-of-memory exception.
> 
> That seems fine to me. This is already the case with the current
> API and implementation, I believe, so we aren't making anything worse.

Hi Kristian and Bryan,

I am assuming that there is no out-of-memory specific exception implemented in Derby, and that you by "out-of-memory exception" mean java.lang.OutOfMemoryError. Please give me a hint if my assumption is wrong...

I believe it is important to distinguish between java Errors and Exceptions, since an Error "indicates serious problems that a reasonable application should not try to catch" [1].


-- 
John


[1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Error.html