Issue with Transactions being Rolled Back

Connecting to SQL
1

I am having some trouble with a script on DreamFactory (2.8.0).

I am posting this here, mostly in case others are experiencing the same problem, but if anyone has a solution, that would be appreciated :slight_smile:

The issue that we have been having is related to the way that transactions are handled. Unfortunately, it is difficult to explain how to replicate the issue without sending across proprietary information:

We have a custom script API running on all 3 servers, which processes an incoming request and updates a number of tables using internal API calls.

  1. A ‘device’ table is updated by either 1 or 2 internal API calls (depending on the source of the device data) with any new information on the incoming JSON concerning the device sending the request
  2. The rest of the request is processed, the data normalised and submitted with ‘rollback=true’ on a second (or third) API call. This call has 2 relationships in it, so the basic structure of the API call is:
    Message
    a. Message data
    b. eventByMessageID
    c. readingByMessageID
  3. For some reason, if the device has taken 2 calls to update, the transaction rolls back in the middle of processing this query

The debugging that we have done so far has led us to find that the transaction is being rolled back at the point that DF attempts to unserialize cached schema information (vendor/laravel/framework/src/Illuminate/Cache/FileStore.php:188). For some reason at this point, it calls the destructor on the SqlDb class (vendor/dreamfactory/df-sqldb/src/Services/SqlDb.php:139). This appears to be disconnecting a service by name, which would be the same service as is currently being used for the transaction.

This may be related to an issue that we were having before – an error (rather than an exception) was being thrown, which older versions of Laravel were not handling correctly, when a connection was no longer available. The fix to this is now in Laravel 5.6 (and I have manually fixed DF on our servers), but that issue was in how an error was handled, not the root cause. This investigation may help to explain why the connection was being dropped in the first place.