Jeżeli transakcje są bardzo długie wówczas klasyczne własności ACID są niewygodne.

Załóżmy, że kilku autorów opracowuje ten sam projekt. Czy dopuszczalna jest sytuacja, że koledzy nie mają możliwości obejrzenia jakiegoś fragmentu projektu, ponieważ facet, który go opracowuje wykonał tam kilka zmian, nie dokończył sprawy i poszedł na dłuższy urlop?

Długie transakcje wymagają osłabienia warunku izolacji lub jakiegoś innego pojęcia szeregowalności. Pewnym rozwiązaniem są poziomy izolacji w SQL.

Pomimo wielu artykułów, w których mówi się jak ten problem jest ważny, nie spotkałem ani jednego, który by jasno przestawił jakieś sensowne i nietrywialne rozwiązanie.

Trywialne rozwiązanie jest oczywiste: specjalny tryb czytania obiektu, który omija nałożone na niego zamki. Tzw. “kuchenne drzwi” (backdoor).

• Transakcje są jednym z najprostszych i najbardziej skutecznych środków zapewnienia bezpiecznego współbieżnego dostępu do wspólnej bazy danych.
• Transakcje mogą być uważane za prosty i w miarę uniwersalny środek synchronizacji równoległych procesów (bez semaforów, monitorów, kanałów i innych trudnych pojęć). Synchronizacja polega na uniemożliwieniu jednoczesnej aktualizacji tych samych zasobów.
• Jednocześnie, transakcje maja zdolność przeciwdziałania losowym awariom.
• Brak środków przetwarzania transakcji w takich systemach jak LotusNotes, MS Office, czy też systemach przepływu prac (workflows) lub pracy grupowej jest ogromnym utrapieniem, które (nie tylko w mojej opinii) w dużym stopniu dyskwalifikuje te narzędzia.
• Transakcje są szczególnie istotne w systemach rozproszonych baz danych lub w systemach opartych o Internet lub Intranet.
• Transakcje są na liście usług poziomych OMG CORBA, są też składnikiem standardów ODMG, SQL3 i Workflow Management Coalition.