>>>>I suggest the two of you agree to limit transactions based on exclusive access to a short transaction duration before releasing the resource to the next object waiting for access...and I'm sure your bladder will want you to use pessimistic beer buffering.
>>>
>>>ROFLMAO!
>>>
>>>BTW, I have, over the years, managed to upgrade my bladder capacity so that I can use optimistic beer buffer instead.
>>
>>Just realize that a failure to Commit a transaction in time can be messy to handle optimistically buffered, or if there's a queue for access to the head which affects the latency of submission! And with beer, a Rollback can be even more unpleasant.
>
>And I have experienced the above. As long as the queue processing time is below, say, 3,600,000 milliseconds, latency isn't much of a problem. However, I do tend to take precautionary measures by making sure the commit is made well within that boundary, so rolling it back is rarely a problem, especially if the facility has mult-stationed heads.

I can remember < vaguely > a couple of episodes of rollbacks after too much Iron City beer in college. Tastes much better handling input and output via separate ports; rollbacks tend to use the same connection for both inbound and outbound beer packets.