All Implemented Interfaces:
TransactionController
All Known Implementing Classes:
RAMTransaction
| Field Summary | ||
|---|---|---|
| static final int | MODE_NONE | Constant used for the lock_level argument to openConglomerate() and openScan() calls. Pass in MODE_NONE if you want no table or row locks. This is currently only supported from within access. |
| public static final int | LOCK_INSTANT_DURATION | release lock immediately after getting lock. |
| public static final int | LOCK_COMMIT_DURATION | hold lock until end of transaction. * |
| public static final int | LOCK_MANUAL_DURATION | Allow lock to be released manually prior to end transaction. |
| Method from org.apache.derby.iapi.store.access.conglomerate.TransactionManager Summary: |
|---|
| addPostCommitWork, checkVersion, closeMe, closeMe, closeMe, getInternalTransaction, getRawStoreXact |
| Method from org.apache.derby.iapi.store.access.conglomerate.TransactionManager Detail: |
|---|
Add to the list of post commit work that may be processed after this transaction commits. If this transaction aborts, then the post commit work list will be thrown away. No post commit work will be taken out on a rollback to save point. This routine simply delegates the work to the Rawstore transaction. |
|
Take whatever cleanup action is appropriate to a closed scan. It is likely this routine will remove references to the scan object that it was maintaining for cleanup purposes. |
Take whatever cleanup action is appropriate to a closed conglomerateController. It is likely this routine will remove references to the ConglomerateController object that it was maintaining for cleanup purposes. |
Take whatever cleanup action is appropriate to a closed sortController. It is likely this routine will remove references to the SortController object that it was maintaining for cleanup purposes. |
Start an internal transaction. An internal transaction is a completely separate transaction from the current user transaction. All work done in the internal transaction must be physical (ie. it can be undone physically by the rawstore at the page level, rather than logically undone like btree insert/delete operations). The rawstore guarantee's that in the case of a system failure all open Internal transactions are first undone in reverse order, and then other transactions are undone in reverse order. Internal transactions are meant to implement operations which, if interupted before completion will cause logical operations like tree searches to fail. This special undo order insures that the state of the tree is restored to a consistent state before any logical undo operation which may need to search the tree is performed. |
Access methods often need direct access to the "Transaction" - ie. the raw store transaction, so give access to it. |