db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: question about synchonization in RAFContainer4.java for page 0 - from DERBY-3347
Date Mon, 16 Jun 2008 12:27:11 GMT
Mike Matrigali <mikem_app@sbcglobal.net> writes:

> There are comments/code in this file about getting synchonization on
> page 0.  I went through the comments in the file and in the derby issue
> and my understanding is that the problem is caused by the behavior on
> windows where the use of a channel affects the current position of the
> file that the channel is based off of.  The case in point is one thread
> using non-channel code to operate on page 0 while another thread is
> using channel code.

I think this code intended to solve a different problem. Consider this
situation:

Thread 1 tries to update the borrowed space on page 0. It does the
following:

  a) synchronize on the container object
  b) read AllocPage.MAX_BORROWED_SPACE bytes from page 0 into a byte
     array
  c) update the borrowed space portion of the byte array
  d) write AllocPage.MAX_BORROWED_SPACE bytes back to page 0
  e) release synchronization on the container object

At the same time in Thread 2, the page cache decides to clean page 0. If
that happens after (b) and before (d), all the non-borrowed space in the
first AllocPage.MAX_BORROWED_SPACE bytes of page 0 will come from the
old version of the page, whereas the rest of the bytes come from the new
version of the page. This means that the new version of page is not
fully written to disk, although the page cache thinks the page is
"clean".

If we synchronize on the container object when cleaning the page, the
above problem goes away, since the cleaning of the page must happen
before (a) or after (e). In those cases we'll always end up with the new
version of the page on the disk. Note that the problem is only present
at page 0, since the cleaning of any other page would not touch the same
bytes as Thread 1.

> What I am missing is why the problem is limited to channel code on page
> 0?  What stops the case of non-channel code operating on page 0 while
> channel code is operating on another page and affecting the non-channel
> page 0 operation?
>
> I considered doing the work to just get rid of the non-channel code, but
> small platform environments including foundation 1.0, 1.1 and 1.1.2
> don't support nio.

I thought all the non-channel code in RAFContainer was overloaded by
methods in RAFContainer4 after DERBY-3347. Which code did you find that
still used the old I/O API when running JDK>=1.4?

-- 
Knut Anders

Mime
View raw message