IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New ACID Saga
I came accross this article [link|http://www.theserverside.com/articles/article.tss?l=AcidShortDoses|Acid is good. Take it in short doses.]

courtsey of [link|http://www.theserverside.com/|theserverside]

I think its pretty nice, well, at least the pieces I understood...

Mainly the article, says, that you cannot preserve ACID attributes for transactions, that need a long time to finish, then, it suggest a method, named SAGA, to overcome, ACID shortcomings.

But it also suggest that creating a SAGA by hand is a headache, so it discuss,
a method/solution, to creating SAGAs

I understood, all, but that HLS/Java Service, they suggest...

It would be nice, to see what other might have to say about this, and maybe explain in more simple words the Java solution thingy

I think the article would have been nicer, if the solution was not explained in terms of Java specefic technologies

Kinda ironic, it seems that investing the time and effort to learn this solution, could turn out to be a bigger headache, then the problem it tries to solve!!!
New Re: ACID Saga simply put and remember Im not a programmer
write small modules that either complete and action or fail completely. Dont forget the module that handles errors. Tie them in a framework, that is what they are speaking about.
regards,
daemon
that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
New Naive approach as well
compensating transactions are useful - but they may not work in a long running transaction either. Its possible to end up with things "wrapped around the axel". You cannot go back and you cannot proceed.

This is a hard problem but the usual approach is to snapshot state you depend on at the beginning of your transaction, then apply your changes to a copy of the state. Before committing your long running edit, you compare your snapshot to the current state of the data. If it matches you may proceed. If it doesn't you throw the whole thing out and tell the user he'll have to start over.

This is common on flight booking systems if you take too long from finding your flight to booking it. Its just the nature of things.



"The significant problems we face cannot be solved at the same level of thinking we were at when we created them."     --Albert Einstein

Step 1: THINK!
Step 2: VOTE!
New Simplified version
The ACID test is whether you satisfy the following conditions:
  • Atomicity - a change is all there or all not, you never see half of it there and half not arrived yet.
  • Consistency - if you have defined any constraints on valid data (eg any person_id must be in the person table) then no transaction will result it in being violated.
  • Isolation - each transaction has a consistent view of the database.
  • Durability - once a change is made, it will be protected against any failure mode that you can protect against.


Any decent relational database will provide these guarantees, and in many applications they matter a lot. Another piece of nomenclature, with transactions people eventually either commit the transaction (save it, let others see it) or rollback the transaction (undo what you did, pretend you never thought of doing this).

It goes on to explain the benefits of ACID. Which are many. And to point out that ACID is not all that you might want - there are stronger conditions. For instance transactions are serializable if any sequence of actions gives the same result as if the independent transactions were done in series. They mention that databases often offer different isolation levels, and you may not be serializable.

If you don't know about this, their explanation will confuse because you won't see how ACID and serialization are different. So I'll give an example - namely Oracle. By default Oracle always tells a transaction that the world looks like it did at the moment that the transaction started. This is ACID but is not serializable. Suppose that two transactions both start at the same time, and each will read a counter and increment it. Both fetch the original value. Both increment that by one. Both save the original value + 1. The counter is therefore incremented by 1. If the one transaction happened after the other, then it would have been incremented by because the second transaction would have seen what the first did. But that isn't what happened - by default Oracle is not serializable.

The article says that ACID is a good thing. Except that providing these guarantees for long-running operations creates operational problems. (I partially disagree with that. For user-facing operations they have a point. For batch processing it can be good even if the operation is very long-running.) They point out that no known transaction algorithm handles this well.

The two known classes of transaction algorithms are optimistic and pessimistic. Optimistic ones hope that there will be no conflict, do work, and then rollback the transaction if there is a problem. Which means that you might unexpectedly throw away a lot of work. Pessimistic ones fear that there will be conflict so they take locks early so that nobody will ruin your work. Now short-lived operations might be blocked indefinitely by a lock. Neither is very good.

They then turn to talking about solutions for long-running applications that don't give you ACID, but they do give reasonable properties and avoid operational problems.

The first is Sagas. In these you do short transactions at defined points. If the whole series of transactions do not complete, you then undo what you did. The example that they gave is that you reserve a hotel room at the first step (be sure that you'll be fine when you get there) and arrange to unreserve it if the person doesn't fill the form out in time.

They mention that Sagas are not well-supported in standards. But J2EE will support JSR 95, which offers tools to support whole classes of transaction models, of which Sagas are but one. (Of course that will be more complex to do in reality than using something that just supports Sagas.) They then explain how to use that to set up Sagas, and then explain how to use that in the toy reservation example that they had. Most of the details of which depend on how JSR 95 works, and so are useless unless you want to use that, or want to set up something equivalent.

Cheers,
Ben

PS I'd expect any competent programmer to be able to look beyond the fact that they were talking about Java to be able to get out most of what I said above. What I would excuse not getting is stuff like how a database can be ACID but not serializable - if you don't know that from experience then you are unlikely to think of it on your own. And that has more to do with how well you understand databases than Java.

PPS I am not a Java programmer.
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
New Regarding the airline reservation example
Generally I create a temp buffer that stores the in-progress info. Only when the *final* "Confirm" button is pressed does it become an ACID transaction. (I prefer "work tables" for such buffers, but there are many alternatives for non-TOP fans.) Generally it requires some kind of unique user or session ID to keep different users' stuff separated. Most web frameworks provide unique session ID's.

I extended this line of thot at:

[link|http://www.c2.com/cgi/wiki?AcidAndLongTransactions|http://www.c2.com/cg...dLongTransactions]
________________
oop.ismad.com
Expand Edited by tablizer Nov. 2, 2004, 01:18:20 AM EST
     ACID Saga - (systems) - (4)
         Re: ACID Saga simply put and remember Im not a programmer - (daemon)
         Naive approach as well - (tuberculosis)
         Simplified version - (ben_tilly)
         Regarding the airline reservation example - (tablizer)

Hello, boys and girls!
48 ms