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!
âmlâ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
