W celu zapewnienia spójności danych w przypadku niepowodzenia wykonania projektu w systemie GRAVITY, został on wyposażony we wbudowany moduł zarządzający 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 trybu Separate transaction oraz Transaction mode=Use separate transaction jawnie ustawionych na kontrolkach), że wszystkie zapytania do baz danych są wykonywane w ramach transakcji oraz, że w przypadku błędu wykonania projektu system wycofa wszystkie zmiany w bazach danych, które zostały wprowadzone w trakcie wykonywania projektu. Natomiast w przypadku zakończenia sukcesem zmiany zostaną zatwierdzone.
Jeśli baza danych na to pozwala system GRAVITY zakłada transakcje o poziomie izolacji Read uncommitted pozwalając na 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
Każdy operator systemu GRAVITY korzystający z połączenia do bazy danych, przed rozpoczęciem przetwarzania, komunikuje się z modułem zarządzania połączeniami bazodanowymi. W trakcie wykonania operator odpytuje się modułu zarządzania 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 przypadku, gdy połączenie nie istnieje, moduł zarządzania tworzy połączenie wykorzystując konfigurację przekazaną przez operator, zakłada transakcję na połączeniu, dodaje je do rejestru połączeń, a następnie zwraca je do operatora. Operator po otrzymaniu połączenia wykorzystuje je do wykonania komendy SQL na bazie danych.
Rejestr połączeń utrzymywany jest w ramach każdego uruchomionego przetwarzania projektu. Po zakończeniu przetwarzania przekazywana jest do modułu zarządzania połączeniami decyzja jak postąpić z transakcjami połączeń do baz znajdujących się w rejestrze przetwarzanego procesu. W zależności od statusu zakończeniu przetwarzania projektu przekazywana jest decyzja o zatwierdzeniu lub odrzuceniu transakcji (potwierdzeniu zmian dokonanych na bazie lub ich wycofaniu). Następnie połączenia do baz danych są zamykane i rejestr połączeń dla wykonywanego projektu czyszczony.
Powyższy sposób działania oznacza, że jeśli w projekcie GRAVITY występuje sytuacja, w której istnieje wiele operatorów korzystających z jednego połączenia do bazy danych to wszystkie te operatory będą działały w ramach jednej transakcji (wyjątek może stanowić operator 
CALL SQL, który może zostać wywołany w odrębnej transakcji - zaznaczone pole Separate transaction).
Gdy w projekcie użytych jest wiele baz danych, system tworzy osobne transakcje dla każdej bazy danych użytej w projekcie, oraz utrzymuje je aż do zakończenia projektu i w zależności od jego rezultatu zatwierdza je lub odrzuca.
CALL SQL tryb Separate transaction nie jest włączony;
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 do operatora połączenia z rejestru połączeń, a zawsze tworzy nowe połączenie z nową transakcją, która zostaje zakończona (zatwierdzone
lub odrzucone) po zakończeniu przetwarzaniu danych na operatorze. Połączenie takie nie trafia do rejestru połączeń i nie będzie użyte przez inne operatory.
Efektem takiego działania jest brak możliwości wycofania zmian na bazie danych wprowadzonych przez operator CALL SQL jeśli projekt nie powiódł się z powodu błędu na dalszych krokach procesu. Natomiast błąd w trakcie wykonania operatora z włączoną opcją Separate transaction spowoduje wycofanie zmian wprowadzony przez ten operator oraz zmian wprowadzonych przez wszystkie połączenia znajdujące się w rejestrze połączeń procesu.
CALL SQL DZIAŁANIE TRYBU TRANSACTION MODE
Tryb Transaction mode jest możliwy do ustawienia w operatorach INPUT OTHER PROJECT oraz OTHER PROJECT CALL , które dają możliwość wywołania innego projektu w ramach projektu aktualnie wykonywanego.
OTHER PROJECT CALL projekt może być wywoływany tyle razy ile jest rekordów 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 ono utworzone i dodane do rejestru. Po zakończeniu procesu podrzędnego nie następuje zakończenie transakcji. 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 odbywa się również na transakcjach utworzonych w procesach podrzędnym.
- Use separate transaction → użycie tego trybu powoduje, że proces podrzędny zachowuje się jak odrębnie wywołany proces. Rejestr połączeń nie jest przekazywany do procesu wywoływanego, a moduł zarządzania połączeniami prowadzi odrębny rejestr połączeń dla wywołania procesu podrzędnego. Po zakończeniu procesu podrzędnego transakcje połączeń tego procesu są zatwierdzane lub wycofywane zgodnie z stanem zakończenia procesu.
OTHER PROJECT CALL ) i każde wywołanie jest traktowane jako oddzielne wywołanie 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 na bazach danych, bądź w innych miejscach środowisk informatycznych, nie są kontrolowane przez środowisko GRAVITY i nie mogą być wycofane
w przypadku błędu wykonania projektu na późniejszym etapie przetwarzania.