public Class ContainerOperation

Implements org.apache.derby.iapi.store.raw.Loggable.doMe.

Doc from org.apache.derby.iapi.store.raw.Loggable.doMe.

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.

Parameters

tran:Transaction

the Transaction

instant:LogInstant

the log instant of this operation

in:LimitObjectInput

optional data

Exceptions

StandardException:

Standard Derby error policy

Implements org.apache.derby.iapi.store.raw.Undoable.generateUndo.

Doc from org.apache.derby.iapi.store.raw.Undoable.generateUndo.

Generate a loggable which will undo this change, using the optional input if necessary.

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.

Parameters

tran:Transaction

the transaction doing the rollback

Returns:Compensation

the compensation operation that will rollback this change, or null if nothing to undo.

Exceptions

StandardException:

Standard Derby error policy

See Also

org.apache.derby.iapi.store.raw.Undoable

Implements org.apache.derby.iapi.services.io.TypedFormat.getTypeFormatId.

Return my format identifier.

Returns:int

Doc from org.apache.derby.iapi.services.io.TypedFormat.getTypeFormatId.

The identifier. (A UUID stuffed in an array of 16 bytes).

Overrides org.apache.derby.impl.store.raw.data.ContainerBasicOperation.readExternal.

Implements java.io.Externalizable.readExternal.

Doc from java.io.Externalizable.readExternal.

The object implements the readExternal method to restore its contents by calling the methods of DataInput for primitive types and readObject for objects, strings and arrays. The readExternal method must read the values in the same sequence and with the same types as were written by writeExternal.

Parameters

in:ObjectInput

the stream to read data from in order to restore the object

Exceptions

IOException:

cannot read log record from log stream

ClassNotFoundException:

cannot read ByteArray object

Overrides org.apache.derby.impl.store.raw.data.ContainerBasicOperation.toString.

debug

Returns:String

Doc from java.lang.Object.toString.

a string representation of the object

Undo of create, drop or remove

Parameters

tran:Transaction

the transaction that is undoing this operation

hdl:RawContainerHandle

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 safe

CLRInstant:LogInstant

the log instant of the CLR

in:LimitObjectInput

optional data

Exceptions

StandardException:

Standard Derby error policy

Overrides org.apache.derby.impl.store.raw.data.ContainerBasicOperation.writeExternal.

Implements java.io.Externalizable.writeExternal.

Doc from java.io.Externalizable.writeExternal.

The object implements the writeExternal method to save its contents by calling the methods of DataOutput for its primitive values or calling the writeObject method of ObjectOutput for objects, strings, and arrays.

Parameters

out:ObjectOutput

the stream to write the object to

Exceptions

IOException:

Includes any I/O exceptions that may occur