A library needs to have a public key in its authentication document when it kicks off the registration process. Currently we do it in the middle of a request to the admin interface: we create a public/private key pair, commit it to the database, kick off the registration process, and remove the key pair once the process completes.

This is the only place where we commit to the database during a request, rather than letting the thread-scoped session take care of it at the end of the request, or creating a subtransaction and committing that. We need to do this because the library registry is going to come in during the processing of this admin request and request the authentication document. When it does, we're going to look in the database for a public key, and it needs to be in there.

This works locally, but in actual deployments it looks like that database commit locks the database so that no requests can be processed until the completion of the request that made the commit. Since completion of the registration process requires handling incoming requests from the library registry, this means that the registration process can't complete.

This is probably related to the thread-scoped session – that has caused similar problems before, problems that show up in real deployments but not in development. Rather than debugging a complicated problem, Amy and I agree that it's fine to generate the public key when the authentication document is requested, and let it live in the authentication document permanently. We don't need a brand new public key for every transaction, which relieves us of the need to a database commit in the middle of a request.