This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
A specific user or subset of users can't start workflows by submitting a Form. When the user(s) submits the Form, it remains on an infinite spinner or hangs completely.
When reviewing the Rule sequence on an affected Form, all Actions prior to the "then start the Workflow" will be executed successfully. The infinite spinner remains once the "then start the Workflow" Action is executing.
When reviewing the Hostserver Log files, the following error messages is seen after the user submits the Form.
"Error","IdentityService","64007","IdentityServiceError","IdentityService.ResolverManager.ResolveIdentityRequest","64007 A server could not obtain a database lock to resolve the identity for '[AffectedUser]' in the configured timeframe."
"Error","IdentityService","64005","ResolvingException","IdentityService.ResolverManager.ResolveIdentityRequest","64005 Failed to resolve '7681': K2:[DOMAIN]\[AffectedUser]."
The issue could be caused if the K2 Database was moved to a different environment, or a node was removed from a clustered environment.
When K2 updates/resolves a User Identity, the identity is temporarily locked against the Server that is processing the Identity. If this K2 server is shut down or stopped while an identity is still locked, it remains locked against that server. When this server is started again, it will complete the processing and set the identity back to unlocked.
Should this server become unavailable, the identity will remain locked against a now, non-existent server. No other server can then process the identity, resulting in the "could not obtain a database lock" error. As the Identity can not be updated/verified, the Workflow cannot be started and the related Form becomes unresponsive.
To confirm the above scenario, please execute the following queries against the K2 Database multiple times:
SELECT * FROM [Identity].[Identity] where [ServerID] <> 0 or [ContainerServerID]<> 0 or [MemberServerID]<> 0
If the affected user or users remain in the results, it may indicate the scenario explained above. Direct K2 database modification will be required to resolve this issue. Please log a K2 Support Ticket on the K2 Customer Portal for assistance in resolving the issue.
No changes to the K2 Database definition or content is supported unless assisted by or specifically instructed to by K2.
Direct read access or modification of the data in the K2 database is also not supported, unless specifically instructed by K2, except for the ServerLog table where direct read access is supported.
Any modification of the K2 database or content may result in system instability or failure, therefore it is highly recommended to make backups of the K2 database prior to performing any modification, even when instructed to do so by K2.
This database schema reference is provided for informational purposes only. Note that database schemas may change between product versions, so if you have written custom queries against the K2 database, those queries may break between product versions.