public class MappedBufferStrategy extends DiskBackedBufferStrategy
Memory-mapped journal strategy (this mode is NOT recommended).
Note: the use of
FileLock with a memory-mapped file is NOT
recommended by the JDK as this combination is not permitted on some
Note: Extension and truncation of a mapped file are not possible with the JDK
since there is no way to guarentee that the mapped file will be unmapped in a
timely manner. Journals that handle
trigger overflow just a bit earlier for a
MappedByteBuffer in an
attempt to avoid running out of space in the journal. If a transaction can
not be committed due to overflow, it could be re-committed after
handling the overflow event (e.g., throw a "CommitRetryException").
The mapped mode has nearly the performance of the transient mode in some tests. However the use of mapped files might not prove worth the candle due to the difficulties with resource deallocation for this strategy and the good performance of some alternative strategies. There are also some other issues that have shown up in some of the tests suites -- look carefully if you are going to pursue this!
bufferMode, commitOffset, ERR_ADDRESS_IS_NULL, ERR_ADDRESS_NOT_WRITTEN, ERR_BAD_RECORD_SIZE, ERR_BUFFER_EMPTY, ERR_BUFFER_NULL, ERR_BUFFER_OVERRUN, ERR_MAX_EXTENT, ERR_NOT_OPEN, ERR_OPEN, ERR_READ_ONLY, ERR_RECORD_LENGTH_ZERO, ERR_TRUNCATE, initialExtent, log, maximumExtent, nextOffset, WARN
|Modifier and Type||Method and Description|
The file channel is closed, but according to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038 there is no way to guarentee when the mapped file will be released.
Overrides the default behavior so that an exception is NOT thrown if the file can not be deleted.
Force the data to disk.
True iff the store is fully buffered (all reads are against memory).
Note: Extension and truncation of a mapped file are not possible with the JDK since there is no way to guarentee that the mapped file will be unmapped in a timely manner.
delete, getChannel, getFile, getHeaderSize, getRandomAccessFile, isStable, read, readRootBlock, setNextOffset, transferTo, writeRootBlock
getBufferView, getCounters, getExtent, getUserExtent, write
abort, assertOpen, closeForWrites, commit, destroy, getBufferMode, getInitialExtent, getMaximumExtent, getMaxRecordSize, getMetaBitsAddr, getMetaStartAddr, getMinimumExtension, getNextOffset, getResourceMetadata, getUUID, isDirty, isOpen, isReadOnly, overflow, requiresCommit, size, transferFromDiskTo, useChecksums
getAddressManager, getByteCount, getOffset, getOffsetBits, getPhysicalAddress, toAddr, toString
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
abort, closeForWrites, commit, getAddressManager, getBufferMode, getCounters, getExtent, getInitialExtent, getMaximumExtent, getMaxRecordSize, getMetaBitsAddr, getMetaStartAddr, getNextOffset, getOffsetBits, getUserExtent, isDirty, requiresCommit, useChecksums
destroy, getResourceMetadata, getUUID, isOpen, isReadOnly, size, write
getByteCount, getOffset, getPhysicalAddress, toAddr, toString
public boolean isFullyBuffered()
Note: This does not guarantee that the OS will not swap the buffer onto disk.
public void force(boolean metadata)
public void close()
public void deleteResources()
public void truncate(long newExtent)
newExtent- The new extent of the journal. This value represent the total extent of the journal, including any root blocks together with the user extent.
java.lang.UnsupportedOperationException- Always thrown.
Copyright © 2006-2014 SYSTAP, LLC. All Rights Reserved.