[jesper.pedersen]

We can split the JIRA no problem.

However, some of those JIRAs needs additional updates - f.ex. there still exists Stack instances after PR675, may as well get them all. And the big changes (synchronized model of Narayana) would require an indepth review.

[marklittle]

Agreed. Enabling TxStats in a performance run is like enabling debugging!

[marklittle]

There's already a JIRA around synchronised methods. But if you've got performance results that illustrate areas of concern (with the right configuration options enabled ) then attach them to the root performance JIRA that I mentioned.

[marklittle]

The Xid wrapper PR is 404 for me too.

[jesper.pedersen]

Whoops, but I removed it last week - [JBJCA-1189] Remove XidWrapper support from the Narayana plugin - JBoss Issue Tracker

Stable branch reference - ironjacamar/core/src/main/java/org/jboss/jca/core/tx/jbossts/XidWrapperImpl.java at 1.1 · ironjacamar/ironjacamar · GitH…

[marklittle]

What's the before and after view of the class look like? No, I don't want to spin up Eclipse

[jesper.pedersen]

The class was just removed, as the XidWrapper SPI was unused in Narayana - [JBJCA-1189] Remove XidWrapper support from the Narayana plugin · b393175 · ironjacamar/ironjacamar · GitHub

[marklittle]

OK hold on ... your original comment mentioned skipping a step around the bqual but now you've deleted the class entirely in your codebase. I must be missing something. Please explain.

[jesper.pedersen]

The constructor of the XidWrapper would do a copy - [JBJCA-1189] Remove XidWrapper support from the Narayana plugin · b393175 · ironjacamar/ironjacamar · GitHub and Narayana calls to the Xid API would clone() - [JBJCA-1189] Remove XidWrapper support from the Narayana plugin · b393175 · ironjacamar/ironjacamar · GitHub

Since the XidWrapper SPI wasn't used it is now up to Narayana to safe guard changes to the branch identifier and so on -- IronJacamar doesn't provide a copy of the byte[] arrays anymore.

[tomjenkinson]

Jesper Pedersen wrote:

Scaling

However, I'm currently blocked on what look to be a main lock somewhere, as the transactions per seconds drops as soon as there is a load on XAResource.start() and XAResource.commit() - e.g. the sleep is != 0. It doesn't seem to matter what the underlying storage implementation is, as both the memory store, and the file store gives the same numbers. But maybe my configuration needs to be adjusted,

Mem store - https://github.com/ironjacamar/ironjacamar/blob/1.2/embedded/src/main/resources/transaction.xml

File store - https://github.com/ironjacamar/ironjacamar/blob/1.2/core/src/test/resources/file-transaction.xml

The attached graph shows this -- the "missing" curves are on top of each other. Any ideas on this would be great.

As you say, it looks like you aren't successfully enabling the volatile store correctly hence the results are the same which is certainly not what I would expect for 2PC transactions. Here is an example of configuration to enable the JDBC object store as an example: narayana/ArjunaJTA/jta/src/test/resources/h2jbossts-properties.xml at master · jbosstm/narayana · GitHub

[marklittle]

You can find out if you've enabled the VolatileStore by calling the appropriate method of StoreManager.

[tomjenkinson]

Hi Jesper,

I see we are up to 5 PRs now for the enhancements. I think it would definitely be useful to have a thread each for these and to discuss each one separately rather than on this main thread as following it is getting confusing.It would also be really great if you could give us an idea of the relative performance benefit for each enhancement that you have identified. I personally thing that although small improvements are still improvements we should get a feel for which improvements are going to provide the greatest wins and focus on those.

Tom

EDIT: Just to clarify too, when I say a different thread I also mean it would be useful to capture each as separate Jiras too so we can audit each commit - thanks

[jesper.pedersen]

Let me investigate the store hints you have given me, and we can get a better idea then. If you want to run the performance test, it is described @ http://www.ironjacamar.org/doc/developerguide/1.2/en-US/html/ch05.html#performance_test_suite

[jesper.pedersen]

I have investigated the IronJacamar setup - the VolatileStore and LogStore are correctly used as the underlying stores in the performance test run. I even tried to initialize StoreManager directly to verify, and even hard coded the default ObjectStoreType in Narayana (ObjectStoreEnvironmentBean).

I have created sub-tasks to JBTM-1300 which can be used for further investigation, and my pull requests can be used as a starting point. Note, that the problem only manifests itself when XAResource.start() and XAResource.commit() takes a while to complete, simulating a real underlying Enterprise Information System.

[marklittle]

Very strange. We have some raw performance tests in ArjunaCore/ArjunaJTA so I may take a look at these tonight if I have time. You should definitely be seeing a significant performance difference between Volatile and Log.