[chiragr]

Hello Paul,

While I am writing my Thesis Proposal, there is an evaluation section where I need to evaluate the work I am doing. In short how can I justify that enabling 1PC is beneficial? Here is my understanding:

• As we know in case of single participant, we can reduce the overhead by cutting down the prepare phase. This will definitely improve the performance (so we can say performance evaluation)
• if there is only a single participant involved in the transaction, the coordinator need not drive it through the prepare phase. Thus, the participant will simply be told to commit and the coordinator need not record information about the decision since the outcome of the transaction is solely down to the participant. (Here can we say that this reduces the chances of failure because coordinator does not record info. If coordinator, during the process of recording info which is not required in this case, faces some failure there is a risk of entire transaction failure)
• Avoiding one phase also reduced the chances of failure

Out of all the above mentioned points only performance evaluation can be shown statistically.

Any other thoughts how can I justify this research? Any help is appreciated. I am also doing the design which I will be sharing with you soon.

Thanks & Regards,

Chirag Rana.

[paul.robinson]

Chirag,

Chirag Rana wrote:

• As we know in case of single participant, we can reduce the overhead by cutting down the prepare phase. This will definitely improve the performance (so we can say performance evaluation)

Agreed. You have fewer messages to send. But the significant improvement comes from the fact that you don't need to write any recovery logs, as the outcome of the transaction is solely the decision on the single resource. Remember, writing recovery logs is more expensive than a typical disk write, as it needs to block until the disk confirms the data is written. You also get a performance improvement in the resource, as it doesn't need to hold locks between the prepare and commit.

• if there is only a single participant involved in the transaction, the coordinator need not drive it through the prepare phase. Thus, the participant will simply be told to commit and the coordinator need not record information about the decision since the outcome of the transaction is solely down to the participant. (Here can we say that this reduces the chances of failure because coordinator does not record info. If coordinator, during the process of recording info which is not required in this case, faces some failure there is a risk of entire transaction failure)
• Avoiding one phase also reduced the chances of failure

I think I agree here too, although I'm not sure I understand the distinction between the two points.

Essentially, by only having one-phase in the protocol, you remove the coupling between the transaction manager and the resource. Thus you remove the possibility of a failure in the TM leaving the resource in a state where it cannot make progress until the TM recovers. In 2PC, a prepared resource must wait to be told the final outcome of the transaction before it can proceed. This notification can come much later if the TM fails and it needs to wait for recovery.

We also discussed earlier, about you implementing recovery. After thinking about this some more, and chatting with Mark, I think the only reason for supporting recovery would be to allow the client to establish the outcome of the transaction in the case of failure. And even then, this would be done on a best-effort basis. It would be impossible for the TM to know the outcome if the failure occurred between the TM telling the resource to commit and getting back the response. I don't think this is a very popular feature, and is not one we provide elsewhere in our other 1PC implementations (to the best of my knowledge).

You should be able to measure the performance gain statistically, as you suggest. For the other motivation, maybe you could code up an example that shows the resource being impacted by a failed TM? You could then show that with 1PC, the same failure does not impact the resource.

Paul.

[chiragr]

Hello Paul,

Thanks so much for your inputs on these points. I will be discussing about this with my thesis advisor this week. I will think if we can find some more points on evaluation. Now soon going to start the implementation in parallel.

Thanks,

Chirag Rana.

[chiragr]

Hello Paul,

I am going to start creating some stand alone webservices. Do you have steps to configure webservice in JBoss AS 7.1? A sample web serivce example running on JBoss would save some time. Any help is appreciated.

Thanks & Regards,

Chirag.

[paul.robinson]

Hello,

JBoss JDF is an excellent resource for examples. See here for the quickstarts: Quickstarts: Get Started

In particular, you may find helloworld-ws to be a good Web Service example. You can then move onto wsat-simple for a simple Web Service using the low-level WS-AT API, which I think is the level you will be working at.

Paul.

[chiragr]

Hello,

Thanks Paul for your inputs. I have started working on web services. Another question I had was I will need the src for WS-AT API instead of a jar file (jbossxts-api-4.16.4.Final.jar). I tried searching and got the source code but it seems to be difficult to setup workspace due to tons of classes in the source which are not necessary. Is there any documentation or reference where I can get the information?

Thanks & Regards,

Chirag.

[paul.robinson]

Chirag,

As you will be adding a feature to XTS, you will need to build it and WildFly from source. It's pretty straight forward once you know what you are doing. I suggest you do the following:

1. Fork Narayana from here: https://github.com/jbosstm/narayana

2. Clone your fork to you computer

3. Build Narayana with "build.sh clean install -DskipTests". This will give you a snapshot build of Narayana, containing your changes if you made them.

4. Clone our fork of WildFly from https://github.com/jbosstm/jboss-as. This fork tracks WildFly master, but is modified to take in the snapshot build of Narayana from step 3.

5. Build Wildfly with:  "build.sh clean install -DskipTests"

6. Look in ./build/target/wildfly-* for the newly built WildFly distribution.

If you want to use an IDE to edit the Narayana source code, I suggest you use the "import from maven project" feature. This will ensure all the dependencies are resolved.

Paul.

[chiragr]

Thanks Paul. This will definitely help. I will keep you posted on this.

[chiragr]

Hello Paul,

Hope you are having a nice time with a new born. I am writing you a personal message as I am not able to post it in our main thread. It keeps me giving this error all the time:

Your content could not be saved due to an error. You may reached frequency limit. Please try it later. Click here to refresh this page.

Is there any issue with forum or our thread?

I am in the process of configuring the project workspace with eclipse IDE. Here are the steps of what is done so far:

Step 1: Created a new dynamic web project in eclipse.

Step 2: Used the wsat restaurant table booking code and created the classes.

Step 3: It gave some compilation errors which was expected.

Step 4: Downloaded the narayana source code.

Step 5: Imported it from maven project in the same workspace

Step 6: Added wstx11 and wst11 as references to my dynamic web project (restaurant table booking) which solved the compilation errors

Step 7: Added the manfiest entries: Dependencies: org.jboss.xts,org.jboss.modules,org.jboss.msc,org.jboss.jts

Step 8: Ran the project and it started working.

Step 9: The workspace does not use jbossxts-api-4.16.4.Final.jar.

Step 10:Then I tried putting some systemouts in enlistForDurableTwoPhase() of com.arjuna.mwlabs.wst11.at.remote.TransactionManagerImple class.

Step 11:But somehow it is picking up the classes from somewhere else and I donot see my sysouts in any of the xts classes.

Step 12:I removed the org.jboss.xts entry from the manifest dependencies as I believe it picks up the xts related classes from the Application server.

Step 13:Now I am getting the UserTransaction object as null in the restaurant client servlet while executing the application.

Any help is appreciated. Looking at the internal code it looks like we should be able to make the changes to introduce our mechanism. Another question I had was is there a method which gives us the number of participants registered in a transaction?

Thanks,

Chirag

[paul.robinson]

Chirag,

It sounds like you are not updating the code in the AS with your changes to XTS. After you make your changes to XTS you need to recompile Narayana and then either rebuild the AS or copy in your new XTS jar over the top of the existing one in the modules directory. I covered this in the message: https://community.jboss.org/message/840277#840277

Paul.

[chiragr]

Hello Paul,

I get it working now. Sorry, I was under the impression that the classes in my deployed project will take precedence to the classes on the server xts. But now I got it after building narayana and wildfly. Thank you so much for your help. Will keep you posted on the progress.

Regards,

Chirag

[paul.robinson]

Great, glad you got it working.

The reason for this is so the deployment artifacts can be as minimal as possible, ideally just working with interfaces, for which the implementations are provided by the application server. Two good reasons for this are that 1) it keeps your deployment artifact small and more importantly 2) by having all implementations provided by the server, we (as AS developers) can ensure that the combination of libraries works well together.

Paul.

[chiragr]

That is correct. It keeps things simple to deploy. Well I had another question about getting number of registered participant. Is there a way, we can get a number of participants registered in a transaction?

Thanks,

Chirag.

[chiragr]

Hello Paul,

How can we show the coordinator failure scenario? In case of 2PC, if there is a coordinator failure, the entire transaction fails as the final decision is dependent upon the transaction coordinator. On the other hand, 1PC scenario can commit the transaction successfully even if transaction coordinator fails because the decision solely depends on the participant. Can you please give some inputs?

Thanks,

Chirag.

[paul.robinson]

Chirag,

In the case where the coordinator fails after the 2PC resource has prepared, but before the resource is told the outcome (commit/rollback), the resource must wait for the coordinator to recover before it can complete the transaction. This might sound unlikely to occur, but the odds increase significantly when you run 100's or 1000's of transactions per second. You can show this by coding up an example that uses Byteman to inject a System.getRuntime().halt() (this does a hard kill on the JVM, and prevents any shutdown hooks from running that might have allowed the transaction to finish cleanly). You should insert this code after the participant has prepared and after the coordinator has written the transaction log.

In the case of 1PC, there is no prepare phase, so it doesn't matter where the transaction is up-to, when the coordinator crashes; the resource will never need to wait for the coordinator to recover.

Paul.