Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 91178 invoked from network); 3 Mar 2006 22:43:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Mar 2006 22:43:20 -0000 Received: (qmail 66372 invoked by uid 500); 3 Mar 2006 22:44:06 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 66137 invoked by uid 500); 3 Mar 2006 22:44:06 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 66128 invoked by uid 99); 3 Mar 2006 22:44:05 -0000 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Mar 2006 14:44:03 -0800 Received: from ajax.apache.org (ajax.apache.org [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id 8C13BDE for ; Fri, 3 Mar 2006 23:43:42 +0100 (CET) Message-ID: <279211456.1141425822571.JavaMail.jira@ajax.apache.org> Date: Fri, 3 Mar 2006 23:43:42 +0100 (CET) From: "Daniel John Debrunner (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-444) Handle OutOfMemoryError exceptions when creating a new embedded connection In-Reply-To: <2130425578.1120682349802.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-444?page=comments#action_12368811 ] Daniel John Debrunner commented on DERBY-444: --------------------------------------------- This is a sub-task of Make Derby engine robust in case of OutOfMemoryError exceptions (DERBY-443) So, yes, one would need to do other changes in other areas, I'm just starting off in one well contained area as a way to see what is possible and to see if I can provide some form of initial framework/useful code. Incremental development, get something simple working quickly and build from there, rather than trying to solve everything completely. I do think something needs to be done in this area (DERBY-443), there is the person on derby-user that put the cache-size up to 10,,000 pages and may be hitting OutOfMemoryErrors, wouldn't it be better if Derby just didn't shutdown with his configuration, instead kept runing after it saw an OOME with a smaller cache. This specific patch/Jira issue doesn't get us there but I'm trying to make a start. I just chose to start with connections. > Handle OutOfMemoryError exceptions when creating a new embedded connection > -------------------------------------------------------------------------- > > Key: DERBY-444 > URL: http://issues.apache.org/jira/browse/DERBY-444 > Project: Derby > Type: Sub-task > Components: JDBC > Reporter: Daniel John Debrunner > Assignee: Daniel John Debrunner > Attachments: derby444_draft_v1.txt > > If an OutOfMemoryError is thrown while creating objects for a new embedded connection, reject the connection request with a SQLException and do not shutdown the system. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira