[rabbitmq-discuss] Fwd: question on the faq

[Tim Coote]

Hi Ben
On 7 Jan 2009, at 22:18, Ben Hood wrote:

>
> 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.
>
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  
vary.
>>
>> 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  
failures.
>
>
> BTW - did Carl ever post you his answer to your problem?
No.
>
>
> Ben
>

Tim Coote
tim at coote.org
vincit veritas