Widzę następujący (obcięty) ślad stosu w pliku server.log JBoss 7.1.1 Final:
Caused by: org.postgresql.util.PSQLException:
ERROR: current transaction is aborted, commands ignored until end of
transaction block
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
at org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455)
at $Proxy49.executeUpdate(Unknown Source) at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:371)
at org.infinispan.loaders.jdbc.TableManipulation.executeUpdateSql(TableManipulation.java:154) [infinispan-cachestore-jdbc-5.1.2.FINAL.jar:5.1.2.FINAL]
... 154 more
Przeglądanie pliku dziennika Postgres ujawnia następujące stwierdzenia:
STATEMENT: SELECT count(*) FROM ISPN_MIXED_BINARY_TABLE_configCache
ERROR: current transaction is aborted, commands ignored until end of transaction block
STATEMENT: CREATE TABLE ISPN_MIXED_BINARY_TABLE_configCache(ID_COLUMN VARCHAR(255) NOT NULL, DATA_COLUMN BYTEA, TIMESTAMP_COLUMN BIGINT, PRIMARY KEY (ID_COLUMN))
ERROR: relation "ispn_mixed_binary_table_configcache" does not exist at character 22
Używam Infinispana dostarczanego z JBoss 7.1.1 Final, czyli 5.1.2.Final.
Więc myślę, że tak się dzieje:
- Infinispan próbuje uruchomić
SELECT count(*)...
instrukcję, aby sprawdzić, czy są jakieś rekordy wISPN_MIXED_BINARY_TABLE_configCache
; - Postgres z jakiegoś powodu nie lubi tego stwierdzenia.
- Infinispan ignoruje to i kontynuuje
CREATE TABLE
oświadczenie. - Postgres barfs, ponieważ nadal uważa, że jest to ta sama transakcja, której Infinispan nie mógł wycofać, a ta transakcja jest przenoszona z pierwszego
SELECT count(*)...
oświadczenia.
Co oznacza ten błąd i jak można go obejść?
postgresql
jboss
infinispan
Jimidy
źródło
źródło
PSQLException: current transaction is aborted...
(25P02
), a może takżeJPA
lubHibernate
. W końcu było to spowodowane naszym (fajnym!) Wykorzystaniem Logbacka zasilanegotoString()
-przeciążonym obiektem DAO, który spowodował błąd i został ładnie połknięty (ale przypadkowo niezauważony przeze mnie):log.info( "bla bla: {}", obj )
wyprodukowanybla bla: [FAILED toString()]
. zmieniając go tak, abylog.info( "bla bla: {}", String.valueOf( obj )
był bezpieczny dla wartości null, ale nie połykał go, a tym samym pozostawiał otwartą transakcję, która kończy się niepowodzeniem w przypadku niepowiązanego zapytania.Odpowiedzi:
Otrzymałem ten błąd przy użyciu Javy i postgresql robiąc wstawkę na stole. Zilustruję, jak można odtworzyć ten błąd:
Podsumowanie:
Powodem, dla którego otrzymujesz ten błąd, jest to, że wprowadziłeś transakcję, a jedno z zapytań SQL nie powiodło się, a Ty pochłonąłeś ten błąd i zignorowałeś go. Ale to nie wystarczyło, WTEDY użyłeś tego samego połączenia, używając TEJ SAMEJ TRANSAKCJI do uruchomienia kolejnego zapytania. Wyjątek jest zgłaszany przy drugim, poprawnie sformułowanym zapytaniu, ponieważ używasz uszkodzonej transakcji do wykonania dodatkowej pracy. Postgresql domyślnie powstrzymuje Cię przed tym.
Używam:
PostgreSQL 9.1.6 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2), 64-bit".
Mój sterownik postgresql to:
postgresql-9.2-1000.jdbc4.jar
Używając wersji java:
Java 1.7
Oto instrukcja tworzenia tabeli ilustrująca wyjątek:
Program Java powoduje błąd:
Powyższy kod daje mi takie wyjście:
Obejścia:
Masz kilka opcji:
Najprostsze rozwiązanie: nie bierz udziału w transakcji. Ustaw
connection.setAutoCommit(false);
naconnection.setAutoCommit(true);
. Działa, ponieważ nieudana instrukcja SQL jest po prostu ignorowana jako nieudana instrukcja sql. Możesz zawieść wszystkie instrukcje sql, a postgresql cię nie powstrzyma.Pozostań w transakcji, ale kiedy wykryjesz, że pierwszy sql nie powiódł się, wycofaj / uruchom ponownie lub zatwierdź / zrestartuj transakcję. Następnie możesz kontynuować niepowodzenie dowolnej liczby zapytań sql w tym połączeniu z bazą danych.
Nie przechwytuj i nie ignoruj wyjątku, który jest generowany, gdy instrukcja sql nie powiedzie się. Następnie program zatrzyma się na źle sformułowanym zapytaniu.
Zamiast tego pobierz Oracle, Oracle nie zgłasza wyjątku, gdy zapytanie dotyczące połączenia w ramach transakcji zakończy się niepowodzeniem i nadal będzie korzystać z tego połączenia.
W obronie decyzji PostgreSQL do robienia rzeczy w ten sposób ... Oracle została czyni cię miękki w środku pozwalając robić głupie rzeczy i wychodzi to.
źródło
rollback()
naConnection
kiedySQLException
zostanie złapany. [W każdym razie zdałem sobie sprawę, że jest to zgodne z filozofią PostgreSQL polegającą na zmuszaniu użytkownika door commit/restart the transaction
. Jak widzę, nie ma sposobu, aby zatwierdzić po wyjątku. Kiedy próbuję zatwierdzić - PostgreSQLrollback
psql
. (1) rozpocząć transakcję, (2) wydać kilka ważnych instrukcji, (3) wydać niepoprawną instrukcję, (4) zatwierdzić -> psql zamiast zatwierdzać wycofa zmiany.savepoints
z funkcji cofnięcia do punktu sprzed aktualizacji / wstawienia. Przykładowy kod znajdziesz na stackoverflow.com/a/28640557/14731 .Sprawdź dane wyjściowe przed instrukcją, która spowodowała
current transaction is aborted
. Zwykle oznacza to, że baza danych zgłosiła wyjątek, który Twój kod zignorował i teraz oczekuje, że kolejne zapytania zwrócą część danych.Masz więc teraz niezgodność stanu między aplikacją, która uważa, że wszystko jest w porządku, a bazą danych, która wymaga wycofania i ponownego rozpoczęcia transakcji od początku.
W takich przypadkach należy wyłapać wszystkie wyjątki i transakcje wycofania.
Oto podobny problem.
źródło
SQL
co spowodowało problem, będziesz mieć pole do wyeliminowania problemu za pomocą rozszerzalności PostgreSQL.Myślę, że najlepszym rozwiązaniem jest użycie java.sql.Savepoint.
Przed wykonaniem zapytania, które może rzucić SQLException, użyj metody Connection.setSavepoint () i jeśli wyjątek zostanie zgłoszony, możesz tylko wycofać się do tego punktu zapisu, a nie wycofać całą transakcję.
Przykładowy kod:
źródło
Wykonano pewną pracę nad sterownikiem JDBC postgresql związaną z tym zachowaniem:
zobacz https://github.com/pgjdbc/pgjdbc/pull/477
Jest to teraz możliwe poprzez ustawienie
w połączeniu (patrz https://jdbc.postgresql.org/documentation/head/connect.html ), aby uniknąć syndromu „bieżąca transakcja została przerwana”.Narzut związany z obsługą punktu zapisu wokół wykonania instrukcji jest utrzymywany na bardzo niskim poziomie (szczegóły w powyższym linku).
źródło
W Ruby on Rails PG utworzyłem migrację, przeprowadziłem migrację mojej bazy danych, ale zapomniałem zrestartować serwer deweloperski. Zrestartowałem serwer i zadziałało.
źródło
Powodem tego błędu jest to, że istnieje inna baza danych, zanim niewłaściwa operacja doprowadzi do bieżącej operacji bazy danych nie może zostać wykonana (używam tłumaczenia google, aby przetłumaczyć mój chiński na angielski)
źródło
Problem został rozwiązany w Infinispan 5.1.5.CR1: ISPN-2023
źródło
Musisz wycofać. Sterownik JDBC Postgres jest dość zły. Ale jeśli chcesz zachować transakcję i po prostu cofnąć ten błąd, możesz użyć punktów zapisu:
Przeczytaj więcej tutaj:
http://www.postgresql.org/docs/8.1/static/sql-savepoint.html
źródło
Miałem ten sam problem, ale potem zdałem sobie sprawę, że w bazie danych znajduje się tabela o tej samej nazwie. Po usunięciu udało mi się zaimportować plik.
źródło
Jest to bardzo dziwne zachowanie PostgreSQL, nawet nie jest to „zgodne z filozofią PostgreSQL, polegającą na zmuszaniu użytkownika do wyrażania wszystkiego jawnie” - ponieważ wyjątek został przechwycony i wyraźnie zignorowany. Więc nawet ta obrona nie wytrzymuje. Oracle w tym przypadku zachowuje się dużo bardziej przyjaznie dla użytkownika i (jak dla mnie) poprawnie - pozostawia wybór deweloperowi.
źródło
Może się tak zdarzyć, jeśli na woluminie brakuje miejsca na dysku.
źródło
Po prostu napotykam ten sam błąd. Udało mi się ustalić główną przyczynę, włączając log_statement i log_min_error_statement w moim lokalnym PostgreSQL.
Skierowałem to
źródło
Używam JDBI z Postgresem i napotkałem ten sam problem, tj. Po naruszeniu jakiegoś ograniczenia z zestawienia poprzedniej transakcji, kolejne wyciągi zawiodłyby (ale po odczekaniu, powiedzmy 20-30 sekund, problem znika ).
Po kilku poszukiwaniach stwierdziłem, że problem polegał na tym, że wykonywałem transakcje „ręcznie” w moim JDBI, tj. Otoczyłem moje oświadczenia słowem BEGIN; ... COMMIT; i okazuje się być winowajcą!
W JDBI v2 mogę po prostu dodać adnotację @Transaction, a wyciągi w @SqlQuery lub @SqlUpdate zostaną wykonane jako transakcja, a wspomniany problem już się nie zdarza!
źródło
W moim przypadku otrzymałem ten błąd, ponieważ mój plik był uszkodzony. Podczas iteracji rekordów plików dawał mi ten sam błąd.
Może w przyszłości pomoże każdemu. To jedyny powód, aby opublikować tę odpowiedź.
źródło
Używam sprężyny z
@Transactional
adnotacją i wychwytuję wyjątek i dla jakiegoś wyjątku spróbuję ponownie 3 razy.W przypadku posgresql, gdy pojawi się wyjątek, nie możesz już używać tego samego połączenia do zatwierdzenia. Najpierw musisz wycofać.
W moim przypadku używam,
DatasourceUtils
aby uzyskać bieżące połączenie i dzwonićconnection.rollback()
ręcznie. I wywołaj metodę recruive, aby ponowić próbę.źródło
Pracowałem z spring boot jpa i naprawiłem, wdrażając @EnableTransactionManagement
Załączony plik może ci pomóc.
źródło
Pracowałem z spring boot jpa i naprawiłem, wdrażając @EnableTransactionManagement
Załączony plik może ci pomóc.
źródło
Spróbuj tego
COMMIT;
Uruchamiam to w pgadmin4. To może pomóc. Ma to związek z przedwczesnym zatrzymaniem poprzedniego polecenia
źródło
Zmień poziom izolacji z odczytu powtarzalnego na przeczytany zatwierdzony.
źródło
Ustaw conn.setAutoCommit (false) na conn.setAutoCommit (true)
Zatwierdź transakcje przed zainicjowaniem nowej.
źródło