Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <14615324.1190292511087.JavaMail.jira@brutus>
Date: Thu, 20 Sep 2007 05:48:31 -0700 (PDT)
From: =?utf-8?Q?J=C3=B8rgen_L=C3=B8land_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2939) Log file is flushed every time a log
 buffer gets full
In-Reply-To: <16955225.1184590264537.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-2939?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529097 ]=20

J=C3=B8rgen L=C3=B8land commented on DERBY-2939:
--------------------------------------

Seems that this is an issue of poor documentation rather than a bug. The as=
sumption that the log record is too big to fit in any LogAccessFileBuffer i=
s correct because the method LogAccessFile.reserveSpaceForChecksum is alway=
s called from LogToFile#appendLogRecord before LogAccessFile.writeLogRecord=
 is called. reserveSpace... allocates a fresh LogAccessFileBuffer if the Lo=
gRecord is too big to fit in the current one.=20

However, there are two remaining issues with LogAccessFile#writeLogRecord t=
hat I would like to address:

1. Document the not too obvious behavior described above.
2. Change what happens when a log record is too big to fit into any of the =
allocated LogAccessFileBuffers the following way:
=20
* Current strategy:=20
------------------------
flushDirtyBuffers (1 disk write for every dirty buffer)
4x disk writes to put the very big log record to disk

* New strategy
-----------------------
flushDirtyBuffers (as above)
allocate a big enough buffer
put the log record into the new buffer
1x disk write to put the giant log record to disk
remove the newly created buffer

Hence, I want to swap 3 disk write operations with main memory operations, =
which should be much faster. Note that the writeLogRecord method is called =
from a synchronized context in LogToFile. Thus, the 4 current disk writes a=
re blocking all other transactions that try to append log.

> Log file is flushed every time a log buffer gets full
> -----------------------------------------------------
>
>                 Key: DERBY-2939
>                 URL: https://issues.apache.org/jira/browse/DERBY-2939
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.3.1.4, 10.4.0.0
>            Reporter: J=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>
> LogAccessFile consists of a number of log buffers: LinkedList<LogAccessFi=
leBuffer> freeBuffers and dirtyBuffers, and LogAccessFileBuffer currentBuff=
er.
> When a log record is written to log, writeLogRecord wrongly assumes that =
the log record is too big to fit in any log buffer if there is not enough f=
ree space in the current log buffer. The code:
> if (total_log_record_length <=3D currentBuffer.bytes_free) {
> <append log record to current buffer>
> ...
> } else {
> <log record too big to fit in any buffer>
> ...
> }
> should be modified to:
> if (total_log_record_length <=3D currentBuffer.bytes_free) {
> <append log record to current buffer>
> ...
> } else if (total_log_record_length <=3D currentBuffer.length) {
> <swap log buffer>
> <append log record to new current buffer>
> ...
> } else {
> <log record too big to fit in any buffer>
> ...
> }

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.