What precisely do you mean by "exactly once"? In the field of reliable distributed systems (of which transactions is just one aspect), the terms "exactly once", "at most once" and "at least once" have well defined meanings, which are typically related to message delivery semantics. For example, http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/icde/2001/1001/00/1001toc.xml&DOI=10.1109/ICDE.2001.914808 and http://searchwebservices.techtarget.com/searchWebServices/downloads/Weer_CH10.pdf
Or do you mean something along the lines of http://www.freepatentsonline.com/4949251.html
I mean the one discussed in
I had to develop this protocol to take my degree. The authors are my professor. It ensures that a transaction when is committed by the user is made one and exactly one time, even if the Application Server (stateless in this case) or the Database Server crash.
Thanks for the reply.
Send me the paper if you can, because I honestly don't see the point: that's just the failure atomicity property of a traditional transaction processing system as far as I can tell.
The protocol is quite simple...
For every transaction made i had to add in a separate table (but in the same Database Server) a row with a unique id and a serializable object that rapresent the expected output of the transaction. It has to be made in a trasparent way.
I added a begin(long id, boolean check) method and a commit(serializable obj) method in the UserEOTransaction (that extends UserTransaction) to implement the protocol.
The problem, now, is that i need the bean name (that invoke the UserTransaction) to set the database table name (that is unique across the namespace), and know in which database the bean store the transaction (this protocol doesn't work in other scenarios). I want that the bean developer add in his ejb.xml the 2 info: if he want to use the EOTransaction or not and the data server url (with 2 new tag... i have to modify the deployer too, i think).
I hope i have better explained my question.
P.S. I have only to implement the protocol to take my degree, the professors made it's correctness proof...
Thanks in advance.
I'd still like to see the paper, because you get failure atomicity by using a transaction manager: it guarantees that a transaction either commits or rolls back even in the presence of failures. Transaction service implementations, such as the new JBoss Transaction Service, use a log to write their intentions list and this is used to ensure that in the event of a failure, either the transaction completes committing, or is rolled back. What you're describing seems to duplicate that.
I can make a couple of example of benefit (my professor certainly can tell a lot more):
First of all: the application server is intended stateless, and then i can add server in every time and in every place... The final user can call every single server, or all the server together. The protocol ensures that only one transaction is executed. You may immagine the scenario where you want to call a lot of server to improve the answer speed(for example Stock Market)...
Second: the protocol ensures that the client always receive an answer. If the client retry the commit the protocol ensures that the client is informed about the previous commit (client want to buy a book; after a few he recommit the transaction; he want to buy only one book, not 2)
There are certanly other benefit, and in the develop of this protocol there are a lot more. Can you suggest me some examples or paper to understand how to resolve my question?
So I can see how you can accomplish what you want with what you've described, but I simply don't see the point if you've got a full distributed transaction system like the one JBoss now offers. In addition, the example of buying books falls squarely in the domain of business-to-business scenarios, which are performed today with off-the-shelf transaction processing systems and application servers.
As an academic excercise I'm sure it may have some place. But in terms of real-world deployments, I just don't see it.
"Can you suggest me some examples or paper to understand how to resolve my question?" If these are your original questions, then I'd suggest asking in the AS forum.
Maybe, but i don't think so...
The stateless server is a very important thing. Immagine to add or remove application server (of any type or vendor) without configure nothing or knowing the other server existence, only in function of the momentary requests... The protocol ensures that the transaction is always made one and exactly one time, even if it's submitted to 2 or more server... The Bean developer is relieved to develop all the logic of re-commit and so on...
For the scenarios in the paper there are a lot of more interesting scenarios, expecially for the big industry (like big computer vendor that want to call all supplier of parts before accept an order)... I think, maybe for inexperience, that can be very usefull to have a function that make the commit retrasmission automatic solving all the problem that can occur...
However this is my task to take my degree and then... :D
I hope that someone could help me to find the answer to the first post question, because this is the last step to finish my task...
Thanks for the replies..