I'm sure Johan Eklund will help me out with this one and jump in if I say something stupid.
So, when we tried to understand MONT-2588 on the Appliance ("Clustering: EJBCA CryptoTokenManager: Generating a key deactivates the Token on other nodes") we found that for some reason, when we generate a Key on a P11-backed CryptoToken, then the according table row get's an unnecessary update, just "rowVersion" and "lastUpdate" get updated, although none of the other columns gets updated. tokenData is empty in case of a hard token. tokenProps showed unmodified.
This leads to the fact that this CryptoToken shows deactivated on the other nodes of this cluster (database is master-master synched in Appliance Cluster), which is confusing all by itself.
Perhaps (I did not go as far as test that) even the according CAs are offline.
In the later course, if a customer tries to activate that CryptoToken back again, he might find that he can activate the CryptoToken without having to enter the (correct) Authentication Code and without having to enter the smart cards which always raises questions about "the security".
I have no knowledge about the code and no idea how explicitly or implicitly this happens through the persistence layer, but it would be really good if the row would not be touched unnecessarily, as in the case of the Appliance.