>>>>>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.
I agree wholeheartedly. I haven't had to do a rollback, however, in a least 15 years, but I do recall it < vaguely >. I think the main problem is the corruption of the beer packet.
George
Ubi caritas et amor, deus ibi est