I am developing a simple Storage Extension for Tridion Docs. In the extension code I have a class that is using LocalThreadTransaction class from the namespace com.tridion.storage.services.LocalThreadTransaction the same way as SI4T class TridionBaseItemProcessor.

The issue is LocalThreadTransaction.getTransactionId() always returns as Null. Any idea what could be wrong with my code?

import com.tridion.storage.extension.models.RestRecord;
import com.tridion.storage.services.LocalThreadTransaction;
import org.slf4j.Logger;

public class SBXItemProcessor {

    public static void addSBXItem(int pubId, RestRecord.operation opr, Logger log)
        log.info("Adding publication:" + pubId + ", for action: " + opr.toString());
        RestRecord record = new RestRecord(pubId, opr);
        SBXIndexProcessor.registerAction(LocalThreadTransaction.getTransactionId(), record);


As answered here, I tried LocalThreadTransaction.get() inside a DAO but it returns null there as well.

  • Saurabh - did you ever resolve this?
    – Neil
    Sep 16, 2020 at 9:51
  • No, I answered my alternative approach and findings. Sep 16, 2020 at 19:53

2 Answers 2


Unfortunately, I did not find a solution to the issue as the issue resides in core libraries.

Currently, for SDL Docs, it is not possible indexing to the data-sources on CommitTransaction method as we do for SDL Sites because of the issue.

For a temporary solution, I start indexing the data to a temporary queue (Azure Servicebus in my case) from JPASearchPublicationDAO class and process this queue record after a few mins assuming the transaction is committed at SDL Docs end. For Ref: (https://github.com/SI4T/SI4T/blob/66b181d9cc5fe769359e17f3f31013a098da0a29/storage-extensions/src/main/java/com/tridion/storage/si4t/dao/JPASearchPageDAO.java#L66)

I know this is not perfect but it works for us because the publishing frequency in docs is quite low.

Few approaches, I would like to try in the future:

  1. Since docs publishing is single-threaded, we could avoid the transaction id because there would always be one publishing transaction in processing. (NOTE: For a single publish in SDL Docs, it results in 4 sub-transactions in the storage layer. So the challenge will be to index the data only once and not 4 times)

  2. In my case, I don't need to index too much data but only publicationId and the publish action so a storage extension seems an overkill. I will try to develop an event plugin (as configured in "Settings -> Write plug-in XML settings") where I catch the publish event and index the data.

Hope this helps.


We had a similar issue and fixed this issue using surrogate keys implemented Cumulative HF CD_11.1.0.19562

For the custom deployer storage extension you might need the following dependency jars.

  • udp-common-config-legacy-11.1.0-1080.jar
  • udp-common-util-11.1.0-1080.jar
  • udp-core-11.1.0-1070.jar
  • udp-data-legacy-transport-11.1.0-1019.jar
  • udp-data-model-compatible-11.1.0-1019.jar
  • udp-datalayer-11.1.0-1110.jar
  • udp-storage-api-11.1.0-1020.jar

In our case, we did Tridion Docs 14SP2 published DXD binaries to the google cloud platform using SI4T based custom deployer storage extension, Tested against DXD 11.1 + CD_11.1.0.19562 Deployer-combined, It was working fine as expected.

I hope it helps.

  • Thanks Velmurugan, I will give it a try. Oct 21, 2020 at 3:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.