Batch revocation of a set of entitlements is implemented by the method CandlepinPoolManager.revokeEntitlements. There are two major implementation goals:
General information about batch revocation of entitlements can be found here
One of the most significant performance gains is thanks to ‘hibernate batch updates’. The idea is that flush() is called after batches of updates to the entities. In the past, every AbstractHibernateCurator.save() call was calling flush(), which is very slow.
The tactic to locking is that we try to lock as many pools as possible with exclusive locks (READ_WRITE). We try to lock as soon as possible so that the batch revoke fails fast, in case locking is not possible. The following snippet is used to mass lock Pool entities.
getEntityManager().createQuery("SELECT p FROM Pool p WHERE p in :pools") .setParameter("pools", poolsToLock) .setLockMode(LockModeType.PESSIMISTIC_WRITE).getResultList();
This note is concerned with runtime consistency of our persistent collections. There is a certain pattern that is used in several of our methods: delete entity X, later use X or some entities in collections of X. By ‘using’ I mean calculating something or navigating through object tree using X. This pattern is used in our code because even after deleting an entity X, it is necessary to do some additional cleanup. Even though useful, one might run into problems when manipulating collections of X. To prevent the problems one has to be very careful about maintaining runtime-consistency (in terms of JPA specification) or they have to store the information about X somewhere else and not use deleted entities further in the code.