Hi,

The book recommends (page 491):
-------------------------------------------------
You may expect that the whole conversation, the two steps, can be rolled back by
closing the unflushed persistence context. The insertion of the newItem is supposed
to be delayed until you call flush() on the Session, which never happens
in this code. This is the case only if you don’t pick identity or select as your
identifier generator. With these generators, an INSERT must be executed in the
second step of the conversation, and the INSERT is committed to the database.
One solution uses compensation actions that you execute to undo any possible
insertions made during a conversation that is aborted, in addition to closing the
unflushed persistence context.
-------------------------------------------------

It will not work because undo operations may fail -- they are not in the same "transaction" as rollback of the original one.

That is why this is called "compensation" and not "transaction rollback". It's not in the same transaction and yes, it might fail too. Then "rolling back" your conversation failed. If you read on you will find out why Solution Two might be better.

I do not see how the word "compensation" can help. It is not worse or better than any other solution, it is not a solution at all, period. This suggestion to solve the problem is wrong and misleading for simple reason: it does not solve it.

Why?

Ok, that was a trick question. I know what you mean. Here is why it's useful:

1. You do an INSERT and you commit it.
2a. You start a new transaction and DELETE the row.
2b. The DELETE commit fails.

Your conversation state is the same after step 1 and after step 2b. You lost nothing.

Would you rather not even try? Wouldn't you say that 2b is extremely rare, rare enough to justify that this exceptional state gets exceptional handling by the user?

It depends on what you mean under "lost". Yes, you do not loose the records but you obtain the garbage - inserted orphan records and this means that the database is not in consistent state anymore - we lost consistent state.

Here we do not need to try because (luckily) we know in advance what happens: data will be not in consistent state very soon. For the sake of discussion I can tell about one real example. I worked on the project which had to provide (for some transition time) an interface (bridge) from the existing database repository to the new I2 supply management software. At that time they had two pieces - one theirs with an (Java) API and another from the acquired company where there was no API to access I2 repository. I needed to use both parts of this software. They suggested to use JDBC for the second part. But it was obvious that there would be two separate connections that had to be run in one transaction. They suggested to rollback one transaction and manually (in code) undo the results the second one. I pointed out immediately that it would not work, but the customer insisted on the suggested implementation. The reality was garbage records surfaced on the first test run.

Another thing. According this books recommendation we can similarly obsolete two phase commit for multiple resources - rollback one and undo others (on the grounds "extremely rare" let say if we have two resources). Who is going to buy it - rhetorical question. Going further we see that embedding transaction management in the database kernel is not simply convenience but rather necessity - we can not rollback manually by undoing partly failed action.

As far as I am concerned this "solution" should be eliminated from this excellent book.

What I describe is an Undo function. Just like the one you use in your text editor. Or all the others you use a dozen times every day. They all don't provide transactional ACID guarantees. If the Undo fails, you have to Undo manually. Like in your text editor.

Please don't say that I recommend to "abandon two-phase commits", that is simply not the truth. I recommend to avoid the situation entirely by delaying the INSERT to the last transaction. If you read carefully, I do _not_ say that the first option you are so upset about is good, recommended, or in any way preferred. That is why it gets treated in a single sentence. That is why I immediately explain a better solution.

The database is always in consistent state when a transaction commits successfully, by the way. It might not be in correct state, but that is something entirely different.

What I describe is related to the "Saga" concept (I think a short Saga could be considered a Conversation, as we describe it, if it's completed inside a single user Session):

http://www.theserverside.com/tt/article ... ShortDoses

And if you don't like me saying "compensation", I guess you won't like it either in the Sun Java blueprints:

http://java.sun.com/blueprints/guidelin ... index.html

And you won't even less like JSR 95, which also covers non-atomic compensation.

Your analogy with text editor is not exact for many reasons, for instance, because it does not have commit - to be more precise it works in autocommit mode - "Save" is the only function to persist the document.

I have never said that you recommended such. I said that similar reasons can be used to abandon two phase commit - I said it, not you.

Correct, you did not wrote that the first option is good solution but my point is that it is not a solution. The second method is a solution - I entirely agree.

Under consistent database I understood the database where enforced ALL business constrains. Some of then can be enforced in database (constraints, triggers), other can be enforced by stored procedures and/or the application. As far as I understand the correct state is when database database constraints fulfilled. But it is not what we want - they are only part of them and we want all of them.

You are right that I do not like this Sun Java blueprints. By the way, I have never seen such recommendations in any database manuals.

Note. Please, do not take it personally - it is is only a technical question and discussion. As to personal: you did a really wonderful job in this book, all other books do not come even close from any aspects of the subject.

So we need to disagree on that. You don't like compensation. Other people are discussing it, are working on standards, and are writing about it. Even if the concept is useless to you, it has value to a lot of people who know that there is a need for non-atomic transaction models. I don't have the time to convince you but you might want to reconsider and research it a little at some point - beyond the database manual.

Yes.

Thank you very much for your time and efforts.