Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

org.apache.derby.impl.store.raw.data
Class ContainerOperation  view ContainerOperation download ContainerOperation.java

java.lang.Object
  extended byorg.apache.derby.impl.store.raw.data.ContainerBasicOperation
      extended byorg.apache.derby.impl.store.raw.data.ContainerOperation
All Implemented Interfaces:
java.io.Externalizable, org.apache.derby.iapi.services.io.Formatable, org.apache.derby.iapi.store.raw.Loggable, java.io.Serializable, org.apache.derby.iapi.services.io.TypedFormat, org.apache.derby.iapi.store.raw.Undoable

public class ContainerOperation
extends ContainerBasicOperation
implements org.apache.derby.iapi.store.raw.Undoable

Log operation to create, drop or remove a container. Both the doMe or the undoMe of a create actually caused the container header to be modified and flushed before the log record is flushed. This is necessary for 2 reasons, one is that of ensuring enough disk space, and the other is because unlike any other operation, the log record create container is in the log stream before the container is in the container cache. What this mean is that if a checkpoint started after the container operation but before the container is kept or is dirtied in the container cache, then checkpoint will not know to wait for the container to be kept or cleaned. The checkpoint will erroneous assume that the operation does not need to be redone since its log instant is before the checkpoint but in fact the change has not been flushed to disk. A drop or remove container does not have this problem. The container exist and is in kept state when the operation is logged so the checkpoint will not overlook it and it doesn't need to flush the container header. In the case of remove, the stub is flushed for a different reason - that of ensuring disk space.


Field Summary
protected static byte CREATE
           
protected  org.apache.derby.iapi.util.ByteArray createByteArray
           
protected static byte DROP
           
protected  boolean hasCreateByteArray
           
protected  byte operation
           
protected static byte REMOVE
           
 
Fields inherited from class org.apache.derby.impl.store.raw.data.ContainerBasicOperation
containerHdl, containerId
 
Fields inherited from interface org.apache.derby.iapi.store.raw.Loggable
ABORT, BI_LOG, CHECKSUM, COMMIT, COMPENSATION, FILE_RESOURCE, FIRST, LAST, PREPARE, RAWSTORE, XA_NEEDLOCK
 
Constructor Summary
  ContainerOperation()
           
protected ContainerOperation(org.apache.derby.iapi.store.raw.data.RawContainerHandle hdl, byte operation)
           
 
Method Summary
 void doMe(org.apache.derby.iapi.store.raw.Transaction tran, org.apache.derby.iapi.store.raw.log.LogInstant instant, org.apache.derby.iapi.services.io.LimitObjectInput in)
          Apply the change indicated by this operation and optional data.
protected  org.apache.derby.iapi.store.raw.data.RawContainerHandle findContainerForLoadTran(org.apache.derby.iapi.store.raw.xact.RawTransaction xact)
          Find container for load tran.
 org.apache.derby.iapi.store.raw.Compensation generateUndo(org.apache.derby.iapi.store.raw.Transaction tran, org.apache.derby.iapi.services.io.LimitObjectInput in)
          Generate a loggable which will undo this change, using the optional input if necessary.
 int getTypeFormatId()
          Return my format identifier.
 void readExternal(java.io.ObjectInput in)
          This method restores an object's state by reading in the instance data for the object from the passed in stream.
 java.lang.String toString()
          debug
 void undoMe(org.apache.derby.iapi.store.raw.Transaction tran, org.apache.derby.iapi.store.raw.data.RawContainerHandle hdl, org.apache.derby.iapi.store.raw.log.LogInstant CLRInstant, org.apache.derby.iapi.services.io.LimitObjectInput in)
          Undo of create, drop or remove
 void writeExternal(java.io.ObjectOutput out)
          This method is responsible for writing the instance data of an object to the passed in stream.
 
Methods inherited from class org.apache.derby.impl.store.raw.data.ContainerBasicOperation
findContainer, getPreparedLog, group, needsRedo, releaseResource
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
 
Methods inherited from interface org.apache.derby.iapi.store.raw.Loggable
getPreparedLog, group, needsRedo, releaseResource
 

Field Detail

operation

protected byte operation

hasCreateByteArray

protected transient boolean hasCreateByteArray

createByteArray

protected org.apache.derby.iapi.util.ByteArray createByteArray

CREATE

protected static final byte CREATE
See Also:
Constant Field Values

DROP

protected static final byte DROP
See Also:
Constant Field Values

REMOVE

protected static final byte REMOVE
See Also:
Constant Field Values
Constructor Detail

ContainerOperation

protected ContainerOperation(org.apache.derby.iapi.store.raw.data.RawContainerHandle hdl,
                             byte operation)
                      throws org.apache.derby.iapi.error.StandardException

ContainerOperation

public ContainerOperation()
Method Detail

writeExternal

public void writeExternal(java.io.ObjectOutput out)
                   throws java.io.IOException
Description copied from interface: java.io.Externalizable
This method is responsible for writing the instance data of an object to the passed in stream. Note that this stream is not a subclass of OutputStream, but rather is a class that implements the ObjectOutput interface. That interface provides a number of methods for writing Java data values to a stream.

Not that the implementation of this method must be coordinated with the implementation of readExternal.

Specified by:
writeExternal in interface java.io.Externalizable
Overrides:
writeExternal in class ContainerBasicOperation

readExternal

public void readExternal(java.io.ObjectInput in)
                  throws java.io.IOException,
                         java.lang.ClassNotFoundException
Description copied from interface: java.io.Externalizable
This method restores an object's state by reading in the instance data for the object from the passed in stream. Note that this stream is not a subclass of InputStream, but rather is a class that implements the ObjectInput interface. That interface provides a mechanism for reading in Java data types from a stream.

Note that this method must be compatible with writeExternal. It must read back the exact same types that were written by that method in the exact order they were written.

If this method needs to read back an object instance, then the class for that object must be found and loaded. If that operation fails, then this method throws a ClassNotFoundException

Specified by:
readExternal in interface java.io.Externalizable
Overrides:
readExternal in class ContainerBasicOperation

getTypeFormatId

public int getTypeFormatId()
Return my format identifier.

Specified by:
getTypeFormatId in interface org.apache.derby.iapi.services.io.TypedFormat

findContainerForLoadTran

protected org.apache.derby.iapi.store.raw.data.RawContainerHandle findContainerForLoadTran(org.apache.derby.iapi.store.raw.xact.RawTransaction xact)
                                                                                    throws org.apache.derby.iapi.error.StandardException
Find container for load tran.

If we are in load tran, and the operation is a create, the container may not (should not?) exist yet. We need to recreate it.

Overrides:
findContainerForLoadTran in class ContainerBasicOperation

doMe

public final void doMe(org.apache.derby.iapi.store.raw.Transaction tran,
                       org.apache.derby.iapi.store.raw.log.LogInstant instant,
                       org.apache.derby.iapi.services.io.LimitObjectInput in)
                throws org.apache.derby.iapi.error.StandardException
Description copied from interface: org.apache.derby.iapi.store.raw.Loggable
Apply the change indicated by this operation and optional data. If this method fail, the system will be shut down because the log record has already been written to disk. Moreover, the log record will be replayed during recovery and this doMe method will be called on the same page again, so if it fails again, recovery will fail and the database cannot be started. So it is very important to make sure that every resource you need, such as disk space, has been acquired before the logAndDo method is called!
This method cannot acquire any resource (like latching of a page) since it is called underneath the logging system, ie., the log record has already been written to the log stream.

The available() method of in indicates how much data can be read, i.e. how much was originally written.

Specified by:
doMe in interface org.apache.derby.iapi.store.raw.Loggable

undoMe

public void undoMe(org.apache.derby.iapi.store.raw.Transaction tran,
                   org.apache.derby.iapi.store.raw.data.RawContainerHandle hdl,
                   org.apache.derby.iapi.store.raw.log.LogInstant CLRInstant,
                   org.apache.derby.iapi.services.io.LimitObjectInput in)
            throws org.apache.derby.iapi.error.StandardException
Undo of create, drop or remove


generateUndo

public org.apache.derby.iapi.store.raw.Compensation generateUndo(org.apache.derby.iapi.store.raw.Transaction tran,
                                                                 org.apache.derby.iapi.services.io.LimitObjectInput in)
                                                          throws org.apache.derby.iapi.error.StandardException
Description copied from interface: org.apache.derby.iapi.store.raw.Undoable
Generate a loggable which will undo this change, using the optional input if necessary.

NOTE
Any logical undo logic must be hidden behind generateUndo. During recovery redo, it should not depend on any logical undo logic.

There are 3 ways to implement a redo-only log record:

  • Make the log record a Loggable instead of an Undoable, this is the cleanest method.
  • If you want to extend a log operation class that is an Undoable, you can then either have generateUndo return null - this is preferred - (the log operation's undoMe should never be called, so you can put a null body there if the super class you are extending does not implement a undoMe).
  • Or, have undoMe do nothing - this is least preferred.

    Any resource (e.g., latched page) that is needed for the undoable.undoMe() must be acquired in undoable.generateUndo(). Moreover, that resource must be identified in the compensation operation, and reacquired in the compensation.needsRedo() method during recovery redo.
    If you do write your own generateUndo or needsRedo, any resource you latch or acquire, you must release them in Compensation.doMe() or in Compensation.releaseResource().

    To write a generateUndo operation, find the object that needs to be rolled back. Assuming that it is a page, latch it, put together a Compensation operation with the undoOp set to this operation, and save the page number in the compensation operation, then return the Compensation operation to the logging system.

    The sequence of events in a rollback of a undoable operation is

  • The logging system calls undoable.generateUndo. If this returns null, then there is nothing to undo.
  • If generateUndo returns a Compensation operation, then the logging system will log the Compensation log record and call Compenstation.doMe(). (Hopefully, this just calls the undoable's undoMe)
  • After the Compensation operation has been applied, the logging system will call compensation.releaseResource(). If you do overwrite a super class's releaseResource(), it would be prudent to call super.releaseResource() first.

    The available() method of in indicates how much data can be read, i.e. how much was originally written.

    Specified by:
    generateUndo in interface org.apache.derby.iapi.store.raw.Undoable

  • toString

    public java.lang.String toString()
    debug

    Overrides:
    toString in class ContainerBasicOperation