Prawie zawsze uruchamiam z autocommit = true. W 99% przypadków moje aktualizacje są atomowe. Jasne, są przypadki, w których piszesz debet, a następnie nie możesz zapisać kwoty, którą chcesz przywrócić. Ale z mojego doświadczenia wynika, że są one stosunkowo rzadkie. Zwykle każdy zapis, który piszę, jest samodzielny. W takim przypadku nie ma potrzeby zajmowania się zatwierdzaniem po każdym zapisie. Zapisuje tu i tam linię kodu. Może zaoszczędzić więcej, jeśli, biorąc pod uwagę strukturę programu, oznacza to, że nie potrzebuję dodatkowego bloku try/catch lub, że nie muszę przekazywać obiektu połączenia między funkcjami. To oszczędza denerwujących błędów, w których ktoś zapomniał zrobić commit.
Jedyny sposób, w jaki widzę, że może "zwabić kogoś w tarapaty" to decyzja, że wyłączenie autocommit i wykonanie commitowania lub wycofania jest zbyt dużym kłopotem, więc robi aktualizacje, które powinny być w ramach transakcji indywidualnie. Wtedy wszystko zaczyna działać tak długo, jak nic się nie wydarzy, co powinno przerwać transakcję. Jeśli scenariusze testowe są niewystarczające, mogę sobie wyobrazić, że to wkracza do produkcji.
Ale można powiedzieć to samo o prawie każdej funkcji języka. Przypuśćmy, że napiszesz program, który przetwarza liczby, które w 90% czasu zmieszczą się w długim, ale co jakiś czas może być większy. W obliczu tej sytuacji, właściwym rozwiązaniem jest użycie BigInteger lub stworzenie nowej klasy, aby obsłużyć większe liczby. Leniwy programista może zostać zwabiony do używania długo, ponieważ zwykle będzie działał, a inne alternatywy są zbyt wielkim problemem. Czy można zatem wnioskować, że Java nie powinna zawierać długich (lub int), ponieważ ktoś może zostać zwabiony do korzystania z nich, gdy nie są odpowiednie?
Jeśli w swoich programach większość aktualizacji musi być wykonana w kontekście transakcji, wyłącz automatyczne zatwierdzanie. Jego obecność nikomu nie szkodzi. Jest tam, kiedy jest wygodny, ale kiedy nie jest, możesz go wyłączyć.
Aby wyjaśnić typowe Ja va + Aplikacja MySQL: ustaw auto-commit na true. Otwórz sesję (i rozpocznij transakcję) raz, na początku przychodzącego żądania (strona internetowa lub REST/JSON). Jeśli żądanie przetwarza się normalnie, zatwierdz transakcję po zakończeniu przetwarzania żądania. Następnie dodaj rolkę do renderowania strony 500 dla żądania. Zasadniczo tak wygląda na przykład struktura Play. Jest intuicyjny dla użytkownika i programisty. –
To jest dobra odpowiedź - "żądanie internetowe" powinno w dużym stopniu korelować z "transakcją DB" w webappie. Dlatego musimy polegać na optymalizacji, a nie blokowaniu DB. Pomaga w korzystaniu z OpenSessionInView do przechowywania sesji otwartej przez całe żądanie, włącznie z wyświetlaniem renderowania, a następnie opróżnianiem/zatwierdzaniem na końcu żądania. –
Moim zdaniem nie jest to dobra odpowiedź, jeśli typowa aplikacja Java + MySQL to coś więcej niż "projekt na kilka tygodni", należy rozważyć sesję otwartą-w-widoku jako antypodstawkę. Szybko stracisz kontrolę nad tym, co dzieje się w twojej aplikacji, praktycznie upewnisz się, że masz problemy z wydajnością lub współbieżnością, autocommit pozostawi Cię bez limitu czasu transakcji lub limitu czasu transakcji działającego jako "czas oczekiwania na żądanie ogólne". Powiedziałbym, że żądanie internetowe NIE koreluje w transakcji SQL w ponad 90% przypadków. –