cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist>
Subject Re: callback for continuation timeout?
Date Tue, 25 Oct 2005 16:22:06 GMT

On Oct 25, 2005, at 12:18 AM, Torsten Curdt wrote:

>> I have some processing invoked from flow that's not OK to just 
>> abandon if the user abandons their session.  In particular, this 
>> processing logic "reserves" some resources in the database.
> BAD BAD BAD!! Don't!!

Why?  What's so BAD about it? :-)

> ...any other way of approaching that logic? What is it?

The application is a ticketing system.  We have to reserve the tickets 
in the database before we process the payment transaction so that we 
don't oversell our tickets.  So, reserving the tickets is transactional 
(using Spring+Hibernate+MySQL), while the payment processing is long 
but non-transactional.  We have to know that we will be able to issue 
the requested number of tickets, before we can bill the customer's 
credit card.

There are other ways to handle this that I can think of, and they are 
are all bad:

1) Process the payment first, with no guarantee of availability.  Once 
payment is secure, attempt to reserve the tickets.  If the requested 
number of tickets are no longer available, then run another transaction 
to reverse the payment.  I really don't like this idea...

2) Just do it all atomically within the transaction.  This is bad for 
two reasons.  First of all, it has *really* poor concurrency 
properties.  Suppose you and I are both trying to purchase tickets at 
the same time, and I win the race and make it into my transaction 
first.  Your transaction will then have to wait for as long as it takes 
mine to complete — including the interaction with the payment processor 
(Verisign) which takes a long time — before yours can even get started, 
and then of course you will have to wait for your own transaction to 
complete before you see any reply.  The second reason it is bad is that 
the design calls for a self-refreshing "please wait, transaction in 
process yada yada" screen to be displayed while the transaction is in 
process.  This requires that the purchase processing be done 
aysnchronously w.r.t. to the client request, and that is impossible if 
it is all to be within a single database transaction, due to lifetime 
issues with the Hibernate Session and Transaction objects 
(specifically: the main thread would be closing the Hibernate Session 
at the end of processing the HTTP request, while the secondary thread 
is still in mid-transaction.  A solution to that would be to use the 
Hibernate "long session" pattern, but that's too invasive of a change 
to make at this point.  BTW you would not like that, you would say it 
is "BAD BAD BAD"! :-) :-)

3) Use a delayed capture on the credit card, i.e. the first transaction 
is an authorization that places a hold on the funds.  Then if the 
attempt to reserve tickets is successful, we follow up with the capture 
transaction.  If we weren't able to reserve the tickets after all, then 
we don't.  This is bad because for multiple reasons that I don't have 
time to go into right now.

4) Periodically run a task that sweeps through the database, 
"harvesting" tickets that were reserved but never committed.

> Something like that *could* be implemented but endorses a bad design.

Well, once again I am most interested to hear just what it is that is 
so bad about the design.  You say "BAD, BAD, BAD" with no explanation, 
so that might as well just be FUD, FUD, FUD!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message