<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
fwiw:<br>
<br>
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.<br>
<br>
>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.<br>
<br>
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.)<br>
<br>
Tim Coote wrote:
<blockquote cite="mid2CC00877-4438-4B1F-8A38-AC5FD42B8088@coote.org"
type="cite">
<pre wrap="">Hi Ben
On 7 Jan 2009, at 22:18, Ben Hood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Tim,
On Wed, Jan 7, 2009 at 12:31 PM, Tim Coote <tim
+rabbitmq.com@coote.org> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Not sure what you mean here? why do I need any exclusive lock?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If the resource that my app's looking to 'get a lock on' gets
consumed, the
transaction aborts. What's the problem?
</pre>
</blockquote>
<pre wrap="">As indicated above, what would be the value of this lock if doesn't
actually lock anything?
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<pre wrap="">
If it's not really a lock, then what implication does this have for
the I in ACID?
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
<blockquote type="cite">
<pre wrap="">
BTW - did Carl ever post you his answer to your problem?
</pre>
</blockquote>
<pre wrap=""><!---->No.
</pre>
<blockquote type="cite">
<pre wrap="">
Ben
</pre>
</blockquote>
<pre wrap=""><!---->
Tim Coote
<a class="moz-txt-link-abbreviated" href="mailto:tim@coote.org">tim@coote.org</a>
vincit veritas
_______________________________________________
rabbitmq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>
<a class="moz-txt-link-freetext" href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>