[rabbitmq-discuss] Fwd: question on the faq
tim+rabbitmq.com at coote.org
Thu Jan 8 12:08:31 GMT 2009
On 7 Jan 2009, at 22:18, Ben Hood wrote:
> 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.
As far as my apps concerned it has exclusive access to some resource
while it's in the transaction. However, the tx can fail for any number
of reasons before it commits. What that means in the real world may
>> 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?
I don't think it's a lock. My app just sees the world in a consistent
state. If I use Oracle, it doesn't lock data that's read, it just
notes what's been looked at and keeps a copy if the data changes. if
the app then tries to commit a tx based on that data, it will fail.
You could implement a lock here if you want, but the type would depend
on how much contention you're expecting.
> If it's not really a lock, then what implication does this have for
> the I in ACID?
None. The I in ACID is about interleaved updates or read
inconsistencies. It's valid for a tx to abort if the world changes.
don't need an exclusive lock to achieve that.
> 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.
So, how would you approach this? Change the high level service so
that it cannot guarantee atomic holiday bookings and leave the process
of sorting out the mess as an exercise for the user? Or build code in
the holiday booking app that tries to second guess what the individual
booking failures mean, which typically leads to a bigger mess,
especially as the failure types change over time. In the meantime,
there's no sensible legal framework for the holiday booking app to
work in, so you don't know who owns any costs of component booking
> BTW - did Carl ever post you his answer to your problem?
tim at coote.org
More information about the rabbitmq-discuss