W celu zapewnienia spójności danych w przypadku niepowodzenia wykonania projektu system GRAVITY został wyposażony we wbudowany moduł zarządzania połączeniami bazodanowymi, który przechowuje połączenia do baz danych w osobnym rejestrze połączeń dla każdego wykonywanego procesu.
System GRAVITY gwarantuje - z wyjątkiem sytuacji, gdy na operatorach jawnie ustawiono tryb Separate transaction lub Transaction mode=Use separate transaction - że wszystkie zapytania do baz danych są wykonywane w ramach jednej transakcji. W przypadku błędu podczas wykonywania projektu system wycofa wszystkie zmiany w bazach danych wprowadzone w jego trakcie, natomiast po pomyślnym zakończeniu projektu zmiany zostaną zatwierdzone.
Jeśli baza danych na to pozwala, system GRAVITY rozpoczyna transakcje z poziomem izolacji Read uncommitted, umożliwiwając tzw. brudne odczyty danych przez inne oprogramowanie, np. biblioteki DLL wywoływane w operatorze 
DLL CALL FUNCTION, serwisy wywoływane w operatorze 
REST API CALL itp.
OGÓLNY SPOSÓB ZARZĄDZANIA TRANSAKCJAMI
Przed rozpoczęciem przetwarzania każdy operator systemu GRAVITY korzystający z połączenia do bazy danych komunikuje się z modułem zarządzania połączeniami bazodanowymi. Podczas wykonywania przetwarzania operator sprawdza, czy zdefiniowane dla niego połączenie do bazy danych istnieje już w rejestrze połączeń procesu.
Jeśli tak, moduł zwraca istniejące połączenie. W przeciwnym przypadku moduł zarządzania tworzy połączenie, wykorzystując konfigurację przekazaną przez operator, rozpoczyna transakcję na połączeniu, dodaje je do rejestru połączeń, a następnie zwraca je operatorowi. Po otrzymaniu połączenia operator wykorzystuje je do wykonania polecenia SQL na bazie danych.
Rejestr połączeń jest utrzymywany dla każdego uruchomionego procesu. Po zakończeniu przetwarzania do modułu zarządzania połączeniami przekazywana jest decyzja, jak postąpić z transakcjami połączeń do baz danych znajdujących się w rejestrze procesu. W zależności od statusu zakończenia przetwarzania projektu przekazywana jest decyzja o zatwierdzeniu lub wycofaniu transakcji (zatwierdzeniu zmian w bazie danych lub ich wycofaniu). Następnie połączenia do baz danych są zamykane, a rejestr połączeń dla wykonywanego projektu jest czyszczony.
Powyższy sposób działania oznacza, że jeśli w projekcie GRAVITY wiele operatorów korzysta z tego samego połączenia do bazy danych, wszystkie będą działały w ramach jednej transakcji. Wyjątek może stanowić operator 
CALL SQL, który może zostać uruchomiony w odrębnej transakcji – po zaznaczeniu opcji Separate transaction.
Jeżeli w projekcie wykorzystywanych jest wiele baz danych, system tworzy osobną transakcję dla każdej z nich i utrzymuje ją do zakończenia projektu, a następnie – w zależności od jego rezultatu – zatwierdza ją lub wycofuje.
CALL SQL tryb Separate transaction nie jest włączony;
- na operatorach 
INPUT OTHER PROJECT oraz 
OTHER PROJECT CALL Transaction mode ma ustawioną wartość Use separate transaction.DZIAŁANIE TRYBU SEPARATE TRANSACTION
Włączenie trybu Separate transaction dostępnego na operatorze CALL SQL powoduje, że moduł zarządzania połączeniami nie przekazuje operatorowi połączenia z rejestru połączeń, lecz zawsze tworzy nowe połączenie z odrębną transakcją, która zostaje zakończona (zatwierdzona lub wycofana) po zakończeniu przetwarzania danych przez operator. Takie połączenie nie trafia do rejestru połączeń i nie jest wykorzystywane przez inne operatory.
Efektem takiego działania jest brak możliwości wycofania zmian w bazie danych wprowadzonych przez operator CALL SQL jeśli projekt zakończy się błędem na dalszych etapach przetwarzania. Natomiast błąd podczas wykonywania operatora z włączoną opcją Separate transaction spowoduje wycofanie zmian wprowadzonych zarówno przez ten operator, jak i przez wszystkie połączenia znajdujące się w rejestrze połączeń procesu.
CALL SQL DZIAŁANIE TRYBU TRANSACTION MODE
Tryb Transaction mode można ustawić w operatorach INPUT OTHER PROJECT oraz OTHER PROJECT CALL , które umożliwiają wywołanie innego projektu w ramach aktualnie wykonywanego projektu.
OTHER PROJECT CALL projekt może być wywoływany tyle razy, ile rekordów znajduje się na magistrali.Tryb Transaction mode może przyjmować dwie wartości:
- Use transaction from main project → użycie tego trybu powoduje przekazanie rejestru połączeń do baz danych do procesu wywoływanego. Oznacza to, że operatory w projekcie wywoływanym korzystają z połączeń do baz danych zdefiniowanych w projekcie nadrzędnym. Jeśli połączenie nie istnieje w rejestrze, zostanie utworzone i dodane do rejestru. Po zakończeniu procesu podrzędnego transakcje nie są kończone. Rejestr połączeń wraca do procesu głównego wraz z połączeniami utworzonymi w procesie podrzędnym. Zatwierdzenie lub wycofanie transakcji po zakończeniu procesu głównego obejmuje również transakcje utworzone w procesach podrzędnych.
- Use separate transaction → użycie tego trybu powoduje, że proces podrzędny działa jak niezależnie wywołany proces. Rejestr połączeń nie jest przekazywany do procesu wywoływanego, a moduł zarządzania połączeniami prowadzi osobny rejestr dla procesu podrzędnego. Po zakończeniu procesu podrzędnego transakcje tego procesu są zatwierdzane lub wycofywane zgodnie ze stanem zakończenia procesu.
OTHER PROJECT CALL ). Każde wywołanie jest traktowane jako oddzielne wykonanie procesu.INNE PROBLEMY ZE SPÓJNOŚCIĄ DANYCH
Projektując procesy, należy mieć na uwadze fakt, że projekt może być zbudowany z wykorzystaniem operatorów wywołujących zewnętrzne usługi (
INPUT REST API, REST API CALL ) bądź kod (DLL CALL FUNCTION, 
CALL EXE).
Zmiany wprowadzone przez wywołane usługi lub kod zewnętrzny w bazach danych bądź w innych miejscach środowiska informatycznego nie są kontrolowane przez środowisko GRAVITY i nie mogą zostać wycofane w przypadku błędu podczas wykonywania projektu na późniejszym etapie przetwarzania.