cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: callback for continuation timeout?
Date Tue, 25 Oct 2005 17:15:16 GMT
Mark Lundquist wrote:

> 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!

IIUC your system reserves the tickets and then charges the credit card. 
If the payment isn't processed than you want to release the tickets.  
What happens if your JVM happens to crash?  Do you have a way of 
completing (or rolling back) the transaction from another JVM?

The problem here is that you really do have a transaction that spans 
both reserving the tickets and paying for them.  It is understandable 
that you don't want the "real" transaction to span all of that, but the 
logical one does anyway. 

Frankly, this is one case where I would look into using a workflow 
engine to manage the full transaction.  Most do a nice job of handling 
all the issues involved and allowing you to specify rules and when to do 
what and how.  Unfortunately, most are oriented towards B2B stuff and 
are heavily biased towards SOAP, which is probably unnecessary in your case.


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

View raw message