If an index is created in the context of a transaction, then rolling it back should delete the index. An index delete in a transaction postpones the actual delete until the transaction is committed. Achieving proper isolation is tricky, as is performing post-commit actions.
This feature is useful for issue #91. Indexes created in the final merge step can be within a single transaction, and they won't be temporary. Other operations like tree grafting still require new redo operations.
Post-commit actions are best performed in the lock-release phase of the transaction, and so some customization is required. The easiest approach is to extend the capability of ghost cursor frames, which are already treated specially as locks are released. A special release action interface is defined, and the ghost cursor frames implement this.
Index/tree creation is isolated by not storing any references to it in the open tree maps. A Lock is retained in the registry, preventing the tree from being accessed outside the transaction. The lock wait is currently infinite, and so a shorter wait and an additional state check might be necessary. An exception can be thrown (or null returned) when trying to open an index which is being deleted by a transaction. The post-commit action needs to read additional state to determine if the transaction was committed or rolled back. If committed, release the registry lock.
One way to use the isolation lock: Currently, the registry lock is acquired upgradable only. After this, explicitly try to upgrade it to exclusive. Normally this works, because no shared lock is held preventing the upgrade. To isolate the index creation, hold a shared lock. Failing to lock exclusive signals that the index is not committed yet.
If an index is created in the context of a transaction, then rolling it back should delete the index. An index delete in a transaction postpones the actual delete until the transaction is committed. Achieving proper isolation is tricky, as is performing post-commit actions.
This feature is useful for issue #91. Indexes created in the final merge step can be within a single transaction, and they won't be temporary. Other operations like tree grafting still require new redo operations.
Post-commit actions are best performed in the lock-release phase of the transaction, and so some customization is required. The easiest approach is to extend the capability of ghost cursor frames, which are already treated specially as locks are released. A special release action interface is defined, and the ghost cursor frames implement this.
Index/tree creation is isolated by not storing any references to it in the open tree maps. A Lock is retained in the registry, preventing the tree from being accessed outside the transaction. The lock wait is currently infinite, and so a shorter wait and an additional state check might be necessary. An exception can be thrown (or null returned) when trying to open an index which is being deleted by a transaction. The post-commit action needs to read additional state to determine if the transaction was committed or rolled back. If committed, release the registry lock.
One way to use the isolation lock: Currently, the registry lock is acquired upgradable only. After this, explicitly try to upgrade it to exclusive. Normally this works, because no shared lock is held preventing the upgrade. To isolate the index creation, hold a shared lock. Failing to lock exclusive signals that the index is not committed yet.