Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Tue, 07 Jun 2005 09:11:28 +0200
From: Oystein.Grovlen@sun.com (=?iso-8859-1?q?=D8ystein_Gr=F8vlen?=)
Subject: Re: [jira] Commented: (DERBY-150) Disable logging
In-reply-to: <42A45C4E.6000104@sun.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <x1of64wqr68v.fsf@atum11.Norway.Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2
Lines: 21
References: <1389432369.1118045080863.JavaMail.jira@ajax.apache.org>
 <x1ofacm3r7wc.fsf@atum11.Norway.Sun.COM> <42A45C4E.6000104@sun.com>

>>>>> "SK" == Shreyas Kaushik <Shreyas.Kaushik@Sun.COM> writes:

    SK> But  turning off  logging  for recovery  operations  could hamper  the
    SK> implementation of Derby's  version of aries algo. Also,  if the log is
    SK> not written to the disk and  is maintianed elsewhere ( main memory ? )
    SK> what do we do in case of hardware/CPU crash how does recovery happen ?
    SK> We'll have  to have an architecture  of failover, is that  a good idea
    SK> for Derby ?

It is a bit unclear from the report whether the submitter needsss to
be able to recover from failures.  If the application only uses the
database for temporary data, it may be OK to start with a fresh
database.   

The submitter says "he never use rollback" and think that he does not
need logging.  I am not sure he really means that it is OK for the
database to become inconsistent should something unforeseen happen
that make it impossible to commit a transaction (e.g., full disk).

-- 
�ystein