...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 ;) <snip/>
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 cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
