JBossDeveloper

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.

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.

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.

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.

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.

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.