lockbasedtxmgr

package
v2.0.0-alpha+incompatible Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Apr 9, 2019 License: Apache-2.0 Imports: 26 Imported by: 0

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

This section is empty.

Types

type LockBasedTxMgr

type LockBasedTxMgr struct {
	// contains filtered or unexported fields
}

LockBasedTxMgr a simple implementation of interface `txmgmt.TxMgr`. This implementation uses a read-write lock to prevent conflicts between transaction simulation and committing

func NewLockBasedTxMgr

func NewLockBasedTxMgr(ledgerid string, db privacyenabledstate.DB, stateListeners []ledger.StateListener,
	btlPolicy pvtdatapolicy.BTLPolicy, bookkeepingProvider bookkeeping.Provider, ccInfoProvider ledger.DeployedChaincodeInfoProvider) (*LockBasedTxMgr, error)

NewLockBasedTxMgr constructs a new instance of NewLockBasedTxMgr

func (*LockBasedTxMgr) Commit

func (txmgr *LockBasedTxMgr) Commit() error

Commit implements method in interface `txmgmt.TxMgr`

func (*LockBasedTxMgr) CommitLostBlock

func (txmgr *LockBasedTxMgr) CommitLostBlock(blockAndPvtdata *ledger.BlockAndPvtData) error

CommitLostBlock implements method in interface kvledger.Recoverer

func (*LockBasedTxMgr) GetLastSavepoint

func (txmgr *LockBasedTxMgr) GetLastSavepoint() (*version.Height, error)

GetLastSavepoint returns the block num recorded in savepoint, returns 0 if NO savepoint is found

func (*LockBasedTxMgr) NewQueryExecutor

func (txmgr *LockBasedTxMgr) NewQueryExecutor(txid string) (ledger.QueryExecutor, error)

NewQueryExecutor implements method in interface `txmgmt.TxMgr`

func (*LockBasedTxMgr) NewQueryExecutorNoCollChecks

func (txmgr *LockBasedTxMgr) NewQueryExecutorNoCollChecks() (ledger.QueryExecutor, error)

NewQueryExecutorWithNoCollChecks is a workaround to make the initilization of lifecycle cache work. The issue is that in the current lifecycle code the cache is initialized via Initialize function of a statelistener which gets invoked during ledger opening. This invovation eventually leads to a call to DeployedChaincodeInfoProvider which inturn needs the channel config in order to varify the name of the implicit collection. And the channelconfig is loaded only after the ledger is opened. So, as a workaround, we skip the check of collection name in this function by supplying a relaxed query executor - This is perfectly safe otherwise. As a proper fix, the initialization of other components should take place outside ledger by explicit querying the ledger state so that the sequence of initialization is explicitly controlled. However that needs a bigger refactoring of code.

func (*LockBasedTxMgr) NewTxSimulator

func (txmgr *LockBasedTxMgr) NewTxSimulator(txid string) (ledger.TxSimulator, error)

NewTxSimulator implements method in interface `txmgmt.TxMgr`

func (*LockBasedTxMgr) RemoveStaleAndCommitPvtDataOfOldBlocks added in v1.4.0

func (txmgr *LockBasedTxMgr) RemoveStaleAndCommitPvtDataOfOldBlocks(blocksPvtData map[uint64][]*ledger.TxPvtData) error

RemoveStaleAndCommitPvtDataOfOldBlocks implements method in interface `txmgmt.TxMgr` The following six operations are performed: (1) contructs the unique pvt data from the passed blocksPvtData (2) acquire a lock on oldBlockCommit (3) checks for stale pvtData by comparing [version, valueHash] and removes stale data (4) creates update batch from the the non-stale pvtData (5) update the BTL bookkeeping managed by the purge manager and update expiring keys. (6) commit the non-stale pvt data to the stateDB This function assumes that the passed input contains only transactions that had been marked "Valid". In the current design, this assumption holds true as we store missing data info about only valid transactions. Further, gossip supplies only the missing pvtData of valid transactions. If these two assumptions are broken due to some bug, we are still safe from data consistency point of view as we match the version and the value hashes stored in the stateDB before committing the value. However, if pvtData of a tuple <ns, Coll, key> is passed for two (or more) transactions with one as valid and another as invalid transaction, we might miss to store a missing data forever if the version# of invalid tx is greater than the valid tx (as per our logic employed in constructUniquePvtData(). Other than a bug, there is another scenario in which this function might receive pvtData of both valid and invalid tx. Such a scenario is explained in FAB-12924 and is related to state fork and rebuilding ledger state.

func (*LockBasedTxMgr) Rollback

func (txmgr *LockBasedTxMgr) Rollback()

Rollback implements method in interface `txmgmt.TxMgr`

func (*LockBasedTxMgr) ShouldRecover

func (txmgr *LockBasedTxMgr) ShouldRecover(lastAvailableBlock uint64) (bool, uint64, error)

ShouldRecover implements method in interface kvledger.Recoverer

func (*LockBasedTxMgr) Shutdown

func (txmgr *LockBasedTxMgr) Shutdown()

Shutdown implements method in interface `txmgmt.TxMgr`

func (*LockBasedTxMgr) ValidateAndPrepare

func (txmgr *LockBasedTxMgr) ValidateAndPrepare(blockAndPvtdata *ledger.BlockAndPvtData, doMVCCValidation bool) (
	[]*txmgr.TxStatInfo, error,
)

ValidateAndPrepare implements method in interface `txmgmt.TxMgr`

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL