IdStory Identity Manager

Some operation locks table in DB, other transactions waits till the lock is unlocked. The waiting is active so IdM soon uns out of DB connections in the pool.

This is an example of what pg_stat_activity table contained before restart:

 16401 | czechidm    |  18816 |    16384 | czechidm    | PostgreSQL JDBC Driver | 10.14.144.79  |                 |       58082 | 2022-10-18 10:25:08.047933+02 | 2022-10-18 10:43:05.479751+02 | 2022-10-18 10:43:15.719019+02 | 2022-10-18 10:43:15.719019+02 | Lock            | transactionid       | active              |   754486271 |    754486192 | update sys_system_attribute_mapping set created=$1, creator=$2, creator_id=$3, modified=$4, modifier=$5, modifier_id=$6, original_creator=$7, original_creator_id=$8, original_modifier=$9, original_modifier_id=$10, realm_id=$11, transaction_id=$12, authentication_attribute=$13, attribute_cached=$14, confidential_attribute=$15, disabled_attribute=$16, echo_timeout=$17, entity_attribute=$18, evict_contr_values_cache=$19, extended_attribute=$20, idm_property_name=$21, name=$22, password_attribute=$23, password_filter=$24, schema_attribute_id=$25, send_always=$26, send_on_password_change=$27, send_only_if_not_null=$28, send_only_on_password_change=$29, strategy_type=$30, system_mapping_id=$31, transform_from_res_script=$32, transform_to_res_script=$33, transformation_uid_script=$34, uid=$35 where id=$36                                                                                                                                                                                                                       | client backend
 16401 | czechidm    |  18818 |    16384 | czechidm    | PostgreSQL JDBC Driver | 10.14.144.79  |                 |       58084 | 2022-10-18 10:25:08.060476+02 | 2022-10-18 10:50:26.13021+02  | 2022-10-18 10:50:26.280107+02 | 2022-10-18 10:50:26.288021+02 | Client          | ClientRead          | idle in transaction |             |    754486265 | select sysattribu0_.id as id1_200_, sysattribu0_.created as created2_200_, sysattribu0_.creator as creator3_200_, sysattribu0_.creator_id as creator_4_200_, sysattribu0_.modified as modified5_200_, sysattribu0_.modifier as modifier6_200_, sysattribu0_.modifier_id as modifier7_200_, sysattribu0_.original_creator as original8_200_, sysattribu0_.original_creator_id as original9_200_, sysattribu0_.original_modifier as origina10_200_, sysattribu0_.original_modifier_id as origina11_200_, sysattribu0_.realm_id as realm_i12_200_, sysattribu0_.transaction_id as transac13_200_, sysattribu0_.attribute_id as attribu16_200_, sysattribu0_.historic_value as histori14_200_, sysattribu0_.value as value15_200_ from sys_attribute_contr_value sysattribu0_ where sysattribu0_.historic_value=$1 and sysattribu0_.attribute_id=$2 limit $3                                                                                                                                                                                                        | client backend
 16401 | czechidm    |  24870 |    16384 | czechidm    | PostgreSQL JDBC Driver | 10.14.144.79  |                 |       32950 | 2022-10-18 10:36:00.560838+02 | 2022-10-18 10:53:26.312952+02 | 2022-10-18 10:53:26.484315+02 | 2022-10-18 10:53:26.492218+02 | Client          | ClientRead          | idle in transaction |             |    754486265 | select sysattribu0_.id as id1_200_, sysattribu0_.created as created2_200_, sysattribu0_.creator as creator3_200_, sysattribu0_.creator_id as creator_4_200_, sysattribu0_.modified as modified5_200_, sysattribu0_.modifier as modifier6_200_, sysattribu0_.modifier_id as modifier7_200_, sysattribu0_.original_creator as original8_200_, sysattribu0_.original_creator_id as original9_200_, sysattribu0_.original_modifier as origina10_200_, sysattribu0_.original_modifier_id as origina11_200_, sysattribu0_.realm_id as realm_i12_200_, sysattribu0_.transaction_id as transac13_200_, sysattribu0_.attribute_id as attribu16_200_, sysattribu0_.historic_value as histori14_200_, sysattribu0_.value as value15_200_ from sys_attribute_contr_value sysattribu0_ where sysattribu0_.historic_value=$1 and sysattribu0_.attribute_id=$2 limit $3                                                                                                                                                                                                        | client backend

There was only one update and a bunch of selects like those above (I have exported the whole table before restart for further investigation). What happened in IdM according the audit log:

1. admin deleted role with mapping of ldapGrops attribute which is "merge" attribut
2. admin created a new role with mappings of ldapGroups attribute (mapping is created automatically by custom processor) - 5 mappings, 8 attributes (3x2 + 2x1)
3. admin assigned the role to several identities
4. then repeated those steps two or free times

I still don't know in which exact situation this happens and I didn't manage to simulate it. But it happened three times in one month in the production environment.