[rabbitmq-discuss] Fwd: question on the faq

[Peter Silva]

fwiw:

I suspect there is no point in looking prior to committing if the state 
isn´t saved, because you get into an endless recursion... say 10 systems 
have to be updated.   When you look, all 10 are ok, but the situation in 
any of the 10 systems could change.  When it comes time to commit, 2 out 
of the 10 systems could have run out of whatever they need to reserve, 
so you end up having to check all 10 again, prior to committing to any 
one.  If they don´t lock this time either, then recurse, recurse again 
with ever smaller intervals...  It doesn´t sound like a robust way to 
proceed.

 From the client perspective, it will look odd as well, the initial 
attempt will work, but when they say confirm it might not.  You aren´t 
giving the client something they can actually purchase.

It makes more sense is if the tentative booking is itself a transaction, 
which does something (ie. grabs the resources being reserved) If you 
want to back out later, that would have to be another transaction.  
There needs to be an application level tag that does everything a real 
reservation does, but marks it as provisional.    A completely separate 
application process could back out of provisional reservations which 
were not confirmed after some period of time. (cancelling provisional 
reservations is a separate application transaction.)

Tim Coote wrote:
> 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
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090108/f92560a4/attachment.htm