Resolution: Cannot Reproduce
Affects Version/s: None
Fix Version/s: None
During a delete operation, a single aggregating transaction is used to persist the deletion of the relevant items. The transaction session we instantiate contains a locks map (of items that belong to that session) that gets populated when Artifactory instantiates a MutableVfsItem.
In operations such as a recursive deletion (i.e a complete repo removal), the children will be loaded recursively from the database starting from the root of the repo all the way down, so getMutableItem (org.artifactory.repo.db.DbStoringRepoMixin#getMutableItem) is called in the same order (path first, then artifacts), so the locks map of the session contains the paths in that same order. We then iterate over the map and delete the items in that order.
There are two problems with that approach:
1.Deletion of big repositories are associated with a single huge transaction
2.If the deletion fails (due to a transaction timeout, hazelcast timeouts, etc), the parents can be removed and orphan children will remain in the database, which will make it impossible to re-create the repo and remove it again (to retry the deletion), and also prevents those artifact entries from being GC'd.
Also see the related: