[rabbitmq-discuss] Fwd: question on the faq

[Ben Hood]

Tim,

On Wed, Jan 7, 2009 at 12:31 PM, Tim Coote <tim+rabbitmq.com at coote.org> wrote:
> Not sure what you mean here? why do I need any exclusive lock?

Because of the implication of this statement from you:

"eg, in the real world, I can make a provisional booking, which times
out if I don't commit to a firm booking within a known (possibly
variable) timeline."

Unless I see this incorrectly, a provisional booking implies
temporally exclusive access to the resource that you have requested.
Were this not the case, a provisional booking would be of questionable
value, because it would only reflect resource availability at the
point in time that the request was processed. Beyond that, this
*booking* would be meaningless.

> This sounds like a scale issue, in general, which will drive the interaction process
> that's feasible. All I want is that what my app understands is the state of
> the world (including entities that are invented to plan the future or model
> uncertainty. Without this guarantee, I don't see how the app works reliably
> anyway.
>
> If the resource that my app's looking to 'get a lock on' gets consumed, the
> transaction aborts. What's the problem?

As indicated above, what would be the value of this lock if doesn't
actually lock anything?

If it's not really a lock, then what implication does this have for
the I in ACID?

What I fail to see here is where the logical unit of work is here if
an external process can affect the outcome of your transaction - e.g.
somebody else actually booking and paying for the plane seats you were
eyeballing whilst your code was waiting for each TX-participant to
reach a consensus.

BTW - did Carl ever post you his answer to your problem?

Ben