- If there is no freeze_date for the contract and no request in t_purge_queue for this contract then the value will be null.
- If there is a freeze_date for this contract and no request in t_purge_queue for this contract then the value will be the freeze_date.
- If there is a freeze_date for this contract and there a request in t_purge_queue for this contract then the current_freeze_date will be the request date and
the previous_lock_date will be the freeze_date and the locking_status will be in progress.
So if you have requested a contract lock, it will first go to the "In Progress" state. This is what should happen when the lock is requested:
For pslWriter to set the calculated data lock, first it has to save the state for all the active time units. It finds the active time units for the rule
select * from t_rules_time_units where rule_id = 1234 and status='ON'
Then for all the active time units for the rule, there should be state saved from the calculated data lock data to the current date
select * from t_rule_states
where rule_id=1234 and level_id = -1
order by timestamp desc
This is how the sequence of events to freeze the contract:
1) When you make a request for a new Data lock, a record is inserted in the t_purge_queue table with status as 'pending' and PURGE_TYPE = 'freeze'
2) When the PSL Writer engine runs it picks up the data from the t_purge_queue table and updates the status to 'active' (these are the records you have in the table currently)
3) For each of these requests in the queue , records inserted into t_purge_agents table with status as 'new'
4) It is important for the Engine to find state for the data lock date in the t_rule_states table for the rule_id. Here is an example query:
select count (*) count from t_rule_states rs
where rs.rule_id=ruleid and rs.time_unit_name='MONTH' and
rs.is_period='1' and rs.level_id=-1 and rs.timestamp='datalock timestamp - 1 second'
5) If the state is found from the above query or if the time unit is not enabled then the freeze_date_line field in the t_rules_time_units table is updated.
6) the records from the t_purge_agents and t_purge_queue are deleted once the step 5 is completed successfully.