Skip to main content

Testing new Domino 12 transaction methods

 Domino V12 EAP contains new methods to manage code transactions. The underlying C API has been there for quite some time, but I've never really looked at it. Now it's finally official and you will be able to leverage these new features in your apps.

The EAP program is currently only shipped as a Docker container, which makes the testing a bit hard - you don't have Domino Designer or easy access to the JVM. The only ways to test the APIs that I could think of were:

  • Try to import the code using DXL on the server - should work for LotusScript
  • Try server-side XPages compilation, e.g. using Jesse's NSF ODP Tooling
  • Build a jar file locally using V12 Notes.jar and reuse that
The last option seemed to be the easiest one and before I had a chance to try it, Ulrich Krause has used that in his test with Java server addin - https://www.eknori.de/2020-11-01/testing-new-database-methods-in-domino-v12-early-access-without-domino-designer-v12/

I wanted to have something more interactive, so I just use the jar from XPages app. 

Testing

So far I've executed just a few scenarios. My primary goal was to find out how close to standard ACID transactions we can get.

Test 1 - simple positive run

Nothing fancy about this. The steps are:
  • start a transaction
  • create and save a document
  • commit the transaction
I use db.search to verify number of documents in the database.


Test 2 - rollback

This is getting a bit more interesting. A rollback - something new for Domino devs.

The code is the same, I just call rollback instead of a commit.


Everything works fine, the document is not permanently stored in the database.

Test 3 - concurrent access

Transactions for a single thread/single-user operations are easy, the real problems start to appear oce things start to happen in parallel. 

I've now added a 5s sleep before the rollback, so I can run this in 2 different browser windows.



All looks good at first sight. The problem is that I definitely did not need 5 seconds to click the button in my second window, so it can only mean that the second execution got blocked for some time, until the first one was closed (with a rollback). This could be easily verified by running one of the previous tests in parallel to the Test 3 - and yes. While alone it was instant, now it finished after the Test 3 execution.

Test 4 - view access

When you have some more complex logic in your app, you may need to do some additional lookups during your transaction. I knew that this is going to be a bit tricky and I was wondering how HCL is handling this as the view index has its own life.

To test this, I've added a check to count all views in a view. First, right after the start of the transaction and then after the save. 


Now the result is not so good - I got an exception. After further testing, it seems that once you save a document in a transaction, you can no longer access any view (not just views that contain the document). 

More to follow

I have not tried DQL or any other operations yet, but I guess I'll do it soon.

Conclusion

Access to the transation APIs is definitely a step forward, but HCL will need to document the limitations. So far it seems to me that once you save a document in a transaction, you basically block all other transactions from being executed and you lose access to views in that database. It completely makes sense as the primary goal of a transactional system is to keep itself in a consistent state, but it will cause a huge performance penalty if not used carefully. It will be also interesting to see how a mix of transactional and non-transactional code behaves. 

Code for the test is on github

The XPage itself is basic - just following for each case:
<xp:panel id="t3">
<xp:button value="Test 3" id="button3">
<xp:eventHandler event="onclick" submit="true"
refreshMode="complete">
<xp:this.action><![CDATA[#{javascript:var tc = new net.pristo.domino.transtest.TestRunner();
viewScope.tr3 = tc.Test03(database);}]]></xp:this.action>
</xp:eventHandler></xp:button>
<br/>
<xp:inputTextarea id="inputTextarea3" readonly="true"
value="#{viewScope.tr3}">
</xp:inputTextarea>
</xp:panel>



Comments

Popular posts from this blog

HCL Domino SSO with Microsoft Teams

 Microsoft Teams is probably one of the most used tools this year, it was already quite popular before the pandemic started to spread across the world this spring, but now most of the businesses I work with use it. After using it just like a chat/conferencing tool, many start to explore further capabilities of the platform. When working with Domino data in apps that are web-enabled, it can be quite easy - just add a web tab anywhere you want. The problem is, that you need to deal with user authentication. 

XPages EL/class-loader memory leak (now with solution)

 We have recently experienced OutOfMemory crashes of XPages app server. The server was recently upgraded to 12.0.1FP1, but we were getting some panic crashes in HTTP even before the upgrade (it was 9.0.1FP10). Our hopes were that the upgrade would stabilize the server, but it's not the case. At least now I start to see what's the problem.  update 8.12.2022 There were actually 3 different leaks. I have rewritten the article to be a bit more clear. I also re-run some of the tests on 9.0.1FP10, so I assume the problems are also in earlier versions. Problem 1 The server is hosting over 1000 NSF sharing the same design + some other custom apps. Not all NSFs are used via web as the app still has classic Notes UI in parallel, so it's a bit tricky to estimate the load. By using tell http xsp show modules I usually see around 350 NSFs active. We kept the default application timeout that should provide reasonable application recycling if it's not used continuously.  We started to

HCL Domino 12.0.2, Engage 2022 and HCL Factory tour Milan

 I haven't published my recap after Engage this year and the recent HCL Factory tour in Milan is a great opportunity to write a summary about what's happening in HCL (mostly Domino) space. It's a mix of news about 12.0.2, future directions, and my impressions, so it can be a bit chaotic, but I got the impression that many people see it similarly.  Engage 2022 Engage 2022 was great (as always). I love the atmosphere in Brudges. I visited it once after Engage a few years ago and I was happy to come back. This was also the first time I had the opportunity to speak at Engage, which obviously made it a bit more stressful, but also more fun. Together with Domino Jams, HCL continued conversations with customers and partners about the future of their products at Engage. Many of these ideas were now discussed in greater detail in Milan, some of them were even demoed.  My main takeaways from Engage were: Nomad (web and mobile) are a great addition to Notes family Restyle is a great g