cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: callback for continuation timeout?
Date Tue, 25 Oct 2005 16:57:34 GMT
>> ...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.

I see

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

I think nobody that will try to buy some tickets would like that idea ;)


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

Well ...TBH in your scenario it's probably not thaaat BAD.
But I fear such a callback could be abused really badly.

I am not really sure how many users are actually aware of the
fact that they should *never* look a component and then release
it after a sendPageAndWait. A callback would legitimate such
a design. It should be obvious that this is a bad idea for
poolable components. But even threadsafe components need to
be released.

So being able to register a callback into the flow on a
timeout seems like a really bad idea to me.

An option that seems ok to me would be to have it not available
inside the flow but provide those hooks on the ContinuationManager.
That's a bit less reachable ...but would solve your problem.

So does that make sense or is it FUD? :-P

BTW: I think we should move that thread over to dev


View raw message