The locker has the ability to set a max timeout for any lock acquisitions. However now that ticket pool size may be smaller, it's more likely for queueing to occur at the ticket acquisition step. Thus we should consider only applying this max timeout to the actual locks and not the ticket acquisition.

In the general case this should be safe because the ticket pools are global resources and therefore there are no ordered concerns with regard to deadlocks. For multi-doc txns which reacquire a ticket out of order with locks, instead of relying on the timeout we can instead detect the deadlock scenario and abort in that case.