I did some brief testing with client-side Trusted Storage based licensing and observed the following:
1) call lc_checkout() to check out a license 2) while license is checked out, use activation utility to return license 3) check license again with lc_checkout() and it still returns success :eek:
I expected that the next call to lc_checkout() would recognize that the license was no longer available and return a failure. Is there some timeout period before lc_checkout() will catch this? :confused:
NOTE: As a quick workaround, I initialize a second job and make an extra lc_checkout() call for the new job with the LM_CO_LOCALTEST parameter just to see if the license is still really there. However, when there are several features to check, I think this redundancy adds significant time delay.
I believe that's normal behavior for client-side trusted storage, analogous to checking out a license from a local node-locked license file and then deleting the file. (The heartbeat exchanges prevent this when using a license server with files or trusted storage.)
As you've seen, a new job handle will reflect the current (changed) state. This behavior is also a reason that back-office systems such as FlexNet Operations typically implement a policy that limits the number of returns within a specified period of time.
To avoid potential execution delays in creating new license jobs (for multiple features) all the time just to catch changes in trusted storage, I implemented a second thread to essentially monitor trusted storage (using Activation API functions) so that I can trigger a checkout from a new job only when something has changed.
Seems to work well... Though, in my opinion, it'd still be nice if subsequent lc_checkout() calls returned an error code indicating that the feature had been transferred/modified, so that my extra threading stuff wouldn't be necessary.
