Long Running Transactions

See http://en.wikipedia.org/wiki/Long_running_transaction

The problem with current LongRunningTransactions support is that it requires too much manual and procedural coding... of course sometimes this is needed, for example if something other than reversing the LongRunningTransaction? effects needs to be done... but when directly reversing those effects is the only thing that needs to be done, I think there should be better tool support to make it an almost automatic task that perhaps could be based in constraints that define if a particular business process is affected by another one and therefore needs to be reversed (or can veto the reversal of the LongRunningTransactions)

I'm fairly sure there is an existing topic on this; I just can't find it yet. [AcidAndLongTransactions?] Anyhow, one approach is to generate an "update list" first, and then apply that update list in a shorter transaction. It is sort of a form of SeparateIoFromCalculation.

Are you certain you understand the context? Any transaction that can be readily reduced to a single 'update list' without intricate interleaving of other reads (potentially from a distributed set of databases) would not qualify to stand among those things one calls 'LongRunningTransactions'. Consider business transactions in particular, where communications must be between two businesses, two independently maintained databases must update as a single atomic action, and the transaction doesn't commit until the deal is closed. The wikipedia page mentions hotel reservations as an example, but doesn't expand on it very well.

I've worked with systems that created "sales proposals". These were basically informal "orders". Once a proposal was approved, someone could press a button and it then became a formal "order". Often multiple proposals were created with various pricing and bundling scenarios. This allowed the customer to study various options. A hotel reservation could be somewhat the same way; you have draft reservations, and they only are submitted as formal reservations when approval is given. These are not really "long running", but merely drafts. The actual transaction would be a typical-duration transaction. I think we need a clearer definition of "long running transaction". -- top

Possible solution: make an isSaleClosed boolean column and mark false when the sale isn't closed (still in proposal). The system does not need to be tied up, the isClosed boolean simply maintains the state of the proposal (which can become a sale). Put an expiry date on the proposals and if they are not closed (turned into sales) within 30 days, delete the row if the customer isn't interested. Store the expiry date in a column too. Ring customer up on the phone and harass them when 30 days is reached - tell them their offer expires in 20 minutes and we need a final answer immediately (or within 2 days). Extend the expiry if they are serious - delete the proposal if they hang up on you. This would not hog up system resources, rather it would make use of database columns for state. Might need to be normalized, I haven't deeply thought about how it would all look - but I think this would be not so hard to solve. I commonly have data in a DB that I have not parsed yet, and I make a boolean column such as "isParsed" and it works very well. Once I have parsed the data I simply mark it parsed. Closing an invoice would be similar. I don't know if this is a LongRunningTransaction?.
In this case, a formal order had more info than a proposal, so a simple flag would not be sufficient. However, it was also denormalized for customer-response performance and a renormalization could perhaps have made a flag approach more effective. But either solution is not a "long running transaction" anyhow.

From http://soa.sys-con.com/read/318438.htm : "Any transaction left in an open state for an indefinite amount of time qualifies as a long-running transaction.". This article should also offer a better explanation than I am able to dedicate the time to offer. -- BlackHat

I see no realistic domain UseCase in there. -- top

Oh? What makes you believe the UseCases they provided (e.g. the money transfer scenario) aren't realistic? And you're always free to check out the references at the bottom of the article and find more use cases; nobody is stopping you from doing your own research, and you shouldn't expect people to spoon-feed you knowledge. If you wish, you can skate by with just knowing that LongRunningTransactions are almost never required unless there are more than two business entities applying business-rules and making decisions in a transaction (i.e. you contact business B which contacts business C) AND late-abort is a realistic possibility. If there are just two entities, it's easy just to use a dedicated transaction to 'cancel' or 'change' a previous arrangement and little need to automatically renegotiate the changes with the other businesses. If there is no late abort, then the transaction isn't open indefinitely. This combination of circumstances isn't unrealistic, but it also isn't common - you're unlikely to encounter it unless you move away from reports and towards service integration (e.g. SOA).

To be frank, it's not my job to hunt down your evidence for your case or issue. -- top

Top, you're obviously grasping for understanding here what LongRunningTransactions mean and how they are used. It is nobody's job but yours to educate you. Statements like "I see no realistic domain UseCase in there" look, to me, like you're just seeking excuses to maintain your ignorance. On this subject I've not even made a "case" or "issue" and so do not need to hunt down evidence for one. So if you're looking for a better understanding of LongRunningTransactions, lay off the arrogance, don't whine, do your own homework, and don't call UseCases "unrealistic" simply because they fall outside your realm of experience.

[Indeed the money UseCase provided is very applicable since a debit/credit has to perform two activities which may take more than a few seconds (even minutes or hours if resources are clogged, and consider if the bank is extremely busy across the world that day). A debit request may invoke a query on an account database located elsewhere in the world over some poor TCP/IP connection (since the bank is busy, and the internet connection is faulty on that day), while the credit portion of the transaction may have similar problems - making the whole transaction risky if we just assume the database inserts and deletions will occur without errors. Banks, are worldwide and connect to remote databases which may be hogged down. Internet connections may also be hogged down.]

[If someone travels 323 miles on a holiday and deposits money at a remote bank.. their bank account isn't going to be stored on a local database at that specific bank location in some server room in that bank. The bank data will located across the world elsewhere.]

[AnswerMe: This begs the question - what did banks do before the internet, in the 1970's or 1960's? How would central account data be updated, without a nation wide network connection (DSL, Cable, Internet)? Tele-transfer I suppose? Dial up? (but they didn't even have modems at a time). Plain old phone calls? MorseCode? Some form of internet that wasn't actually the internet, back then? I suppose they used mainframes at some central location in the country - and had some form of technically ahead of its time "phone internet". I'm just guessing, as I have no experience in the banking industry sadly. Even worse: what did they do in the 1800's when they didn't have databases, transactions, queries?]

I'm certain you could also do a little digging on your own and find out quickly enough. Look it up. What I can say for certain is that far more humans were involved in the loop, meaning slower and more expensive services.

I'm certain that most of the information on C2 wiki must be useless since people can just look it up elsewhere then too.
There's a huge difference between finding information already on the wiki and childishly demanding someone else do your homework for you. If you request an 'AnswerMe' without doing your homework first, you deserve a kick in the teeth, or at least a significant helping of shame-on-you. Above, he should have just looked up the answer and made any relevant comment.

Ideally, it seems there should be a central broker or "certification service" to coordinate the transactions, it can then use a single-server ACID. If not, then each party probably would want confirmation from each participant before it commits. But this can get tricky if one party flakes. They become the bottleneck. A central trusted broker simplifies things. Still, this is about "multi-party" transactions, not "long-running".

Use of a central broker or transaction coordinator is common to most implementations of LongRunningTransactions, but the potential for late abort still prevents single-server ACID.