Ability to add hook/handler on JDBC transaction success for SQL type datasources...

[kshaw2019]

Hi Isomorphic Support,

For SQL defined data sources, is there a way to add a handler/hook after the JDBC transaction has been fully processed successfully (not rollback).

This can be for cases when there is one or many records processed successfully. Is there a way we can hook into this workflow so that we can do our own specific server side processing on post JDBC transaction success.

We are aware of the feature to implement own DMI handler for the datasource (defining own serverObject with DMI handler specified), but is there any other means to achieve this?

Thank you.

[Isomorphic]

As you noted, it’s possible to add a DMI either on the last normal operation, or as a special last operation that has no automatic SQL action (operationType:”custom”). We’re not sure why that would be inconvenient - it seems to handle basically any scenario? Can you explain what’s wrong with that approach?

Note that with overrides in IDACall like processRequest(), you can put logic around any queue of requests (SQL or not).

[michaelplavnik]

1. Could you please point to the Docs how to add DMI on the "last" operation?
2. I got an impression that DMI operation is invoked inside transaction (not after commit). Correct me if I am wrong, or there is an option...
3. Adding special operation that has no automatic SQL action might be a good solution to a different problem, like adding logic at the end of commit of set of records from related data sources. I am looking to a simple to use (may be not simple to code, but generic) way to add "trigger" like behavior that is independent on the invocation sequence. The difference with trigger is that it need to be invoked AFTER transaction commits.

[Isomorphic]

For #1 and #2, take a look at the QuickStart Guide, Server Framework chapter, specifically you want the discussion on the server processing flow, on operationId and how that works, and then also the section on non-CRUD operations.

A DMI can either be part of the transaction or before it or after it; it depends on whether you use one of the default transaction policies or manage transactions explicitly (see eg DSTransaction).

As far as being after the automatic transaction, if you have configured the automatic transaction to include all requests by default, then as we previously covered an override of IDACall.processRequest is one approach, that would let you add code after the default transaction has been committed. Another would be RPCManager.registerCallback().