Class ContainerOperation
- All Implemented Interfaces:
Externalizable
,Serializable
,Formatable
,TypedFormat
,Loggable
,Undoable
- See Also:
-
Field Summary
FieldsModifier and TypeFieldDescriptionprotected static final byte
protected ByteArray
protected static final byte
protected boolean
protected byte
protected static final byte
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
ConstructorsModifierConstructorDescriptionprotected
ContainerOperation
(RawContainerHandle hdl, byte operation) -
Method Summary
Modifier and TypeMethodDescriptionfinal void
doMe
(Transaction tran, LogInstant instant, LimitObjectInput in) Apply the change indicated by this operation and optional data.protected RawContainerHandle
Find container for load tran.generateUndo
(Transaction tran, LimitObjectInput in) Generate a loggable which will undo this change, using the optional input if necessary.int
Return my format identifier.void
toString()
debugvoid
undoMe
(Transaction tran, RawContainerHandle hdl, LogInstant CLRInstant, LimitObjectInput in) Undo of create, drop or removevoid
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 Details
-
operation
protected byte operation -
hasCreateByteArray
protected transient boolean hasCreateByteArray -
createByteArray
-
CREATE
protected static final byte CREATE- See Also:
-
DROP
protected static final byte DROP- See Also:
-
REMOVE
protected static final byte REMOVE- See Also:
-
-
Constructor Details
-
ContainerOperation
- Throws:
StandardException
-
ContainerOperation
public ContainerOperation()
-
-
Method Details
-
writeExternal
- Specified by:
writeExternal
in interfaceExternalizable
- Overrides:
writeExternal
in classContainerBasicOperation
- Throws:
IOException
-
readExternal
- Specified by:
readExternal
in interfaceExternalizable
- Overrides:
readExternal
in classContainerBasicOperation
- Throws:
IOException
- cannot read log record from log streamClassNotFoundException
- cannot read ByteArray object
-
getTypeFormatId
public int getTypeFormatId()Return my format identifier.- Specified by:
getTypeFormatId
in interfaceTypedFormat
- Returns:
- The identifier. (A UUID stuffed in an array of 16 bytes).
-
findContainerForRedoRecovery
protected RawContainerHandle findContainerForRedoRecovery(RawTransaction xact) throws 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:
findContainerForRedoRecovery
in classContainerBasicOperation
- Throws:
StandardException
- Standard Derby error policy.
-
doMe
public final void doMe(Transaction tran, LogInstant instant, LimitObjectInput in) throws StandardException Description copied from interface: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 interfaceLoggable
- Parameters:
tran
- the Transactioninstant
- the log instant of this operationin
- optional data- Throws:
StandardException
- Standard Derby error policy
-
undoMe
public void undoMe(Transaction tran, RawContainerHandle hdl, LogInstant CLRInstant, LimitObjectInput in) throws StandardException Undo of create, drop or remove- Parameters:
tran
- the transaction that is undoing this operationhdl
- the container handle. This is found here during runtime undo - in which case we made the CLR and passed in the containerHdl found in generateUndo and it is passed back to this; or it is found in the CLR's needsRedo and is passed in and this operation never found the container. Either case, release resource at the end is safeCLRInstant
- the log instant of the CLRin
- optional data- Throws:
StandardException
- Standard Derby error policy
-
generateUndo
Description copied from interface: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 interfaceUndoable
- Parameters:
tran
- the transaction doing the rollback- Returns:
- the compensation operation that will rollback this change, or null if nothing to undo.
- Throws:
StandardException
- Standard Derby error policy- See Also:
-
toString
debug- Overrides:
toString
in classContainerBasicOperation
-