[
https://issues.apache.org/jira/browse/DERBY-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-1068:
----------------------------------
It is still not totally concurrent but the procedure meant to be used to allow
concurrent access to the table and compressing the table at same time is:
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE
The COMPRESS_TABLE function guarantees best compression, but will always do so
by getting
exclusive access to the table, and internally creating brand new base tables
and indexes and loading
those from the old table while holding the exclusive lock.
INPLACE_COMPRESS_TABLE is "more" online, but does still have one phase that
requires
an exclusive lock.
Also wondering if maybe it is not necessary to run compress if you plan on
inserting into table. Derby
does reuse space in the table when subsequent inserts come in. The level of
reuse tends to be when a whole page of data becomes deleted.
> change of store contract: online compress operations should not share any
> locks with user transactions
> ------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1068
> URL: https://issues.apache.org/jira/browse/DERBY-1068
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Reporter: Andreas Korneliussen
> Assignee: Mike Matrigali
> Priority: Minor
>
> Propose to add the following to the store contract:
> * truncate and compress requires exclusive table locking
> * the truncate, purge and compress operations do not share any locks with
> user transactions
> Currently the store implementation allows users to share locks in truncate
> and possibly purge.
> This request is driven by:
> http://www.nabble.com/conflict-detection-strategies-t1120376.html#a2938142
> and:
> http://www.nabble.com/RowLocation-contract-from-storage-engine-t1142235.html#a2994156
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
