I'm new here

Zugriff für diese Transaktion kann nicht serialisiert werden


ich bekomme vermehrt beim Freigeben von Datensätzen (FS5) die folgende Fehlermeldung.

Jemand eine Idee?

Hört sich nach einem grundsätzlichen Problem an?

Caused by: java.sql.SQLException: ORA-08177: Zugriff für diese Transaktion kann nicht serialisiert werden

    at oracle.jdbc.driver.T4CTTIoer.processError(

    at oracle.jdbc.driver.T4CTTIoer.processError(

    at oracle.jdbc.driver.T4C8Oall.processError(

    at oracle.jdbc.driver.T4CTTIfun.receive(

    at oracle.jdbc.driver.T4CTTIfun.doRPC(

    at oracle.jdbc.driver.T4C8Oall.doOALL(

    at oracle.jdbc.driver.T4CPreparedStatement.doOall8(

    at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(

    at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(

    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(

    at oracle.jdbc.driver.OracleStatement.doScrollExecuteCommon(

    at oracle.jdbc.driver.OraclePreparedStatement.doScrollPstmtExecuteUpdate(

    at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(

    at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(

    at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(

    at de.espirit.or.impl.TemporalCommandHandler.getLastReleasedEntry(

    at de.espirit.or.impl.TemporalCommandHandler.handle(

    at de.espirit.or.impl.ReleaseCommand.accept(

    at de.espirit.or.impl.AbstractSessionHandler.commit(

    at de.espirit.or.impl.AbstractSessionHandler.commit(

    at de.espirit.firstspirit.content.ContentManagerImpl$TemporalSessionHandler.commit(

    at de.espirit.firstspirit.content.ContentManagerImpl.commit(

    at sun.reflect.GeneratedMethodAccessor6175.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(

    at java.lang.reflect.Method.invoke(





    at de.espirit.firstspirit.server.ExecutionManagerImpl$

    at de.espirit.firstspirit.server.ExecutionManagerImpl$


    at de.espirit.common.util.BoundedExecutorService$

    at java.util.concurrent.Executors$


    at java.util.concurrent.ThreadPoolExecutor.runWorker(




    at de.espirit.firstspirit.server.$Proxy36.commit(Unknown Source)


    at de.espirit.or.impl.SessionImpl.doCommit(

    at de.espirit.or.impl.AbstractSession.commit(


3 Replies
I'm new here

der fix ist hier in der Layer/jdbc Konfiguration: "jdbc.isolation=READ_COMMITTED" zu setzen. das bezieht sich nur auf oracle.

Set transaction isolation mode to TRANSACTION_READ_COMMITTED and see

ORA-08177 no more. See last paragraph of this posting for how. If you

use no entity beans (ie. direct JDBC from a session bean) and / or run

in a clustered multi-app-server shared-database env, you might want to

look closer though:

ORA-08177 is only possible in TRANSACTION_SERIALIZABLE (WLS default) tx

isolation mode. Are you sure that you need this (strictest) level of

transaction isolation ? Do you genuinely have multiple transactions

updating and reading the same data ? Even so,

TRANSACTION_READ_COMMITTED is often quite sufficient, provides better

concurrency, is almost as strict (no dirty reads of uncommitted data),

and I recall it to be an Oracle default.

This said, TRANSACTION_SERIALIZABLE is necessary in cases where you

really need to prevent chronologically overlapping transactions from

seeing each other's committed modifications or record additions

("non-repeatable reads/phantom inserts" as laid out by ISO SQL92).

But for instance, in a simple case of EJB1.1 entity bean single-server

configuration TRANSACTION_SERIALIZABLE and ORA-08177 would most of the

time be an unnecessary nuisance, because by EJB1.1 definition the

container locks access to entity instances exclusively by one

transaction at a time. Thus inconsistent reads would seem impossible

there, because a single (ie. the same) entity instance would be used for

the immediately consecutive reads in any case. (gurus, make my day.

Rather, please correct me if I'm all wrong, since I do want to

understand this problem correctly

IMHO, WLS 5.1 .. WLS 7.0 documentation could provide a little more

verbose understanding of the RDBMS tx isolation modes in the J2EE

context and mention READ_COMMITTED for Oracle (with its restrictions for

databases shared in a cluster, perhaps), or provide pointers to

3rd-party documentation, because this still seems to be a frequent

headache for developers. A FAQ-candidate perhaps ? I found this link

helpful (you need Oracle technet access):

Hallo David,

benötigst du noch weitere Hilfe oder hat Andrés Antwort zur Lösung des Problems geführt? In diesem Fall wäre es super, wenn du seine Antwort als "richtige Antwort" markierst.

Viele Grüße


0 Kudos

Wir sind noch dran das Problem nachzustellen und zu beheben. Den Fix haben wir bereits auf unserem Testsystem installiert. Soabld wir das System erfogreich getestet haben, markiere ich die Antwort auch als Richtig.

0 Kudos