Skip to main content
15-Moonstone
March 1, 2019
Question

Does Thingworx support distributed transaction?

  • March 1, 2019
  • 8 replies
  • 2802 views

Hi,

 

I wonder when a transaction service calls other transaction services but they don't use the same DatabaseThing to query/store data, are these database transactions managed by a single transaction scope?

 

My Bests,

Hung Tran

8 replies

22-Sapphire I
March 4, 2019

Do you mean Thingworx transactions against different DataTables/Streams?

Behind the scenes that all goes through one single JDBC connection pool to the Database (the Persistence Provider)

 

as far as 'transactions' go, i do believe that if one part fails and all the calls are in the same service it will reverse the full 'transaction'. Although I recommend testing that to verify.

1-Visitor
March 5, 2019

As far as I know, a transaction starts when you call a service (and it continues to any called inner service) and ends at the end of the services, if an exception it's thrown the whole transaction it's rolled back --> This it's what creates Ghosts when you are creating entities and an Exception it's thrown.

htran-2115-MoonstoneAuthor
15-Moonstone
March 5, 2019

Hi CarlesColl,

 

It is interesting now, i did a test. Thingworx does not manage transaction well. Let's see a simple test

 

Service TestDistributedTransactionWithError () 
{
 var conn1 = Things['TestDataAdapter'];
 var conn2 = Things['TestDataAdapter1'];

 conn1.TestSQLCommand(); // insert a row
 conn2.TestSQLCommand(); // insert a row

 conn1.RaiseError(); // database error level
 conn2.RaiseError(); // database error level

 // Both connections should not be committed, but they did

 throw 'service error level'
}

When the service ran, i got an error, but all rows are committed. It means, Autocommit mode is enabled on every live connections. On the other hand, the TestDistributedTransactionWithError is not a transaction service, only SQLCommand is done in an implicit transaction (Autocommit is On).

 

Another issue, I retried the test above with Autocommit=true in connection string, but the result is the same. It means that setting is overridden / unmanaged by code (connection.setAutocommit(false/true) is not called in a scope of invoking service).

 

My Bests,

Hung Tran