UserTransaction

[sks]

Hi at all,
i'm modifying the UserTransaction to implent "Exactly once" behaviour...
I've modified the getUserTransaction() method in the class BaseSessionContext adding this line (to allow the downcast):

return (UserTransactionImpl) new UserEOTransactionImpl();

I've extended the UserTransaction interface and implemented the UserEOTransactionImpl();

For now the protocol is intentionally limited to the BMP with a single database. Now to finish i have some questions (i hope that aren't too silly):

1. How can i know which Bean instantiate the UserTransaction?
2. My protocol need to have some info about the Bean that instantiate the transaction. I'd like to read this info from the deploy info (like Bean name, transaction type,...); How can i do?
3. Finally i want to extend the xml that the programmer make adding a 2 new tag; the fisrt one is to tell if he want to use traditional or EO transaction, the second to tell which is the URL of the database he want to use. Someone can help me?

If is useful i can post all the code of this modify.
Please, reply to this post. Thanks in advance.
Andrea C.

[marklittle]

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

Mark.

[sks]

I mean the one discussed in

http://ieeexplore.ieee.org/iel5/69/32375/01512041.pdf?tp=&arnumber=1512041&isnumber=32375

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.

[marklittle]

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.

Mark.

[sks]

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.

[marklittle]

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.

Mark.

[sks]

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?
Thanks...

[marklittle]

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.

Mark.

[sks]

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..