Dear seam2 users,

From time to time (about 1 of 100 requests) I can observe the following non-deterministic transaction cleanup behavior in a Seam 2.3 application running either on wildfly 8 or 9:

-> 1. post request e.g. Edit (1st transaction)

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) before phase: RESTORE_VIEW 1

DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) beginning transaction prior to phase: RESTORE_VIEW 1

DEBUG [org.jboss.seam.transaction.UTTransaction] (default task-31*) beginning JTA transaction

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) after phase: RESTORE_VIEW 1

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) before phase: APPLY_REQUEST_VALUES 2

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) after phase: APPLY_REQUEST_VALUES 2

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) before phase: PROCESS_VALIDATIONS 3

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) after phase: PROCESS_VALIDATIONS 3

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) before phase: UPDATE_MODEL_VALUES 4

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) after phase: UPDATE_MODEL_VALUES 4

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) before phase: INVOKE_APPLICATION 5

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) after phase: INVOKE_APPLICATION 5

DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (default task-31) committing transaction after phase: INVOKE_APPLICATION 5

DEBUG [org.jboss.seam.transaction.UTTransaction] (default task-31*) committing JTA transaction

-> 2. get after redirect e.g. List (2nd transaction)

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-32) before phase: RESTORE_VIEW 1

DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (default task-32) beginning transaction prior to phase: RESTORE_VIEW 1

DEBUG [org.jboss.seam.transaction.UTTransaction] (default task-32**) beginning JTA transaction

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-32) after phase: RESTORE_VIEW 1

DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (default task-32**) committing transaction after phase: RESTORE_VIEW 1

DEBUG [org.jboss.seam.transaction.UTTransaction] (default task-32) committing JTA transaction

TRACE [org.jboss.seam.jsf.SeamPhaseListener] (default task-32) before phase: RENDER_RESPONSE 6

DEBUG [org.jboss.seam.jsf.SeamPhaseListener] (default task-32) beginning transaction prior to phase: RENDER_RESPONSE 6

DEBUG [org.jboss.seam.transaction.UTTransaction] (default task-32***) beginning JTA transaction

!!

INFO  [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl] (default task-31*) HHH000106: Forcing container resource cleanup on transaction completion                                                    ^^

!!

--> JdbcCoordinatorImpl.afterTransaction() is called by task-31 much too late yet during the 2nd transaction and is cleaning up resources used in the 2nd transaction causing an exception (result set closed etc.)

Analyzing the caller stack of JdbcCoordinatorImpl.afterTransaction() where the resource cleanup takes place reveals that org.jboss.seam.transaction.UTTransaction is the last non-container caller element that can be considered part of the webapp.

As the application manages the beginning and committing of the JTA transactions in sequences it must be some container functionality that postpones the execution of the cleanup or allows the beginning of the next transaction before finishing the cleanup of the last transaction.

I would really appreciate your explications and possible solutions for this behavior.

MiguelZ