Is resend action in JdbcTransactionalStorage non-transacted

[alisihab]

❗ please do not add sensitive information in issues, you can provide extra information via email using issue number as reference ❗

Describe the issue I had a few messages in error store. I resent the messages. All failed to be processed at some point in the pipeline. But the messages are never returned to the error store.

Below I paste the receiver and the pipeline. The pipeline throws an error when resolving the ServiceCode param since the messageContext is not stored in the error store the contextKey is not available and converting NULL to number fails. However, the message in error store are not restored.

<receiver numThreads="4" transactionAttribute="Required">
            <listener name="FF_Common_1" destinationName="dest.queue" lookupDestination="false" queueConnectionFactoryName="jms/qcf" messageProtocol="FF" className="nl.nn.adapterframework.extensions.esb.EsbJmsListener"/>
            <errorStorage slotId="/FF_Common_1" className="nl.nn.adapterframework.jdbc.JdbcTransactionalStorage"/>
        </receiver>
        <pipeline>
            <exit name="EXIT" state="SUCCESS"/>
            <exit name="ERROR" state="ERROR"/>
            <pipe name="logStart" className="nl.nn.adapterframework.pipes.LogContextPipe">
                <param name="ibis" value="und"/>
                <param name="service" value="Configuration_FF_Common_1"/>
                <param name="service_type" value="SOAP"/>
                <param name="conversationId" sessionKey="soapHeader" xpathExpression="//*:ConversationId" defaultValue="notfound"/>
            </pipe>
            <pipe name="Call StoredProcedure" storeResultInSessionKey="output" className="nl.nn.adapterframework.pipes.SenderPipe">
                <sender datasourceName="jdbc/oracle" timeout="30" query="{ ? = call test(?, ?, ?) }" queryType="other" className="nl.nn.adapterframework.jdbc.StoredProcedureQuerySender">
                    <param name="output" mode="OUTPUT" type="CHARACTER"/>
                    <param name="ServiceCode" sessionKey="originalMessage" contextKey="ServiceCode" type="NUMBER"/>
                    <param name="Content" type="CHARACTER"/>
                    <param name="P_stub" value="FALSE"/>
                </sender>
                <forward name="timeout" path="TimeoutError"/>
            </pipe>

Reporter Ali/Jeroen

FF: 7.9-20230811.190015

[nielsm5]

Receiver#retryMessage is transactional?

[nielsm5]

Retrying will create a new transaction using the TX_NEW definition. It will then propagate to the default flow, taking the Receiver's transactionAttribute into account. Explicitly setting it is not required.

If you set it to NotSupported it will remove the transaction and process the message untransacted. (This is not a likely scenario because you wouldn't be able to use the ErrorStorage if that's the case 🤭.

[jjansenvr]

We should rename this issue to "When messages are resend from the errorstore and run into error they disappear"

It could be the fact that we are using a non XA database connection and the adapter is transacted and connects to JMS?

How it could work better!

• Message is picked up from the errorstore (dbtable) status is set to in progress
• Message is put on the adapter If an exception occurs:
  • The error result is updated in the database
  • Resend history is added (user | dateTime | number of try)
  • The message is kept for resending if the message is processed without errors
  • the status is updated to succes
  • expiry date is set

[nielsm5]

Created issue #6393

[jjansenvr]

At this time the errorstore needs to use a transactional datasource for the errorstore to work correctly. This is tested and has the required behavior.

As a feature it would be nice to have the setup as described earlier in this issue so we can use similar solution as used for the error store on filesystem. Add a hook to resend via a schedule and even have a resend history.

[jjansenvr]

We can close the issue and I will create a feature request https://github.com/frankframework/frankframework/issues/6428