Description of problem: A migrated Seam2.2 Booking example on EAP6 shows a deadlock between org.jboss.seam.core.SynchronizationInterceptor and stateful component instance EJB lock during an ajax request. Reformattd exceprt from the log: 13:28:32,944 http--127.0.0.1-8080-1 Trying to acquire Seam SynchronizationInterceptor hotelSearch lock 13:28:32,947 http--127.0.0.1-8080-1 Acquired Seam SynchronizationInterceptor hotelSearch lock 13:28:32,978 http--127.0.0.1-8080-1 Trying to acquire lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3effb100 [State = 0, empty queue][Unlocked] 13:28:32,979 http--127.0.0.1-8080-1 Acquired lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3effb100 [State = 1, empty queue][Locked by 0:ffff7f000001:20b3094f:4f9e7717:46] 13:28:32,980 http--127.0.0.1-8080-1 Registered tx synchronization for tx: 0:ffff7f000001:20b3094f:4f9e7717:46 associated with HotelSearchingAction 13:28:32,985 http--127.0.0.1-8080-1 HotelSearchAction.isNextPageAvailable called 13:28:32,987 http--127.0.0.1-8080-1 Released Seam SynchronizationInterceptor hotelSearch lock 13:28:32,992 http--127.0.0.1-8080-2 Trying to acquire Seam SynchronizationInterceptor hotelSearch lock 13:28:32,993 http--127.0.0.1-8080-2 Acquired Seam SynchronizationInterceptor hotelSearch lock 13:28:32,994 http--127.0.0.1-8080-2 Trying to acquire lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3effb100 [State = 1, empty queue][Locked by 0:ffff7f000001:20b3094f:4f9e7717:46] 13:28:33,034 http--127.0.0.1-8080-1 Trying to acquire Seam SynchronizationInterceptor hotelSearch lock Here is the deadlock, resolved by the Seam SynchronizationInterceptor timeout 13:28:34,034 http--127.0.0.1-8080-1 timeout on Seam SynchronizationInterceptor hotelSearch lock 13:28:34,258 http--127.0.0.1-8080-1 Before completion callback invoked on Transaction synchronization: ... Instance of HotelSearchingAction 13:28:34,259 http--127.0.0.1-8080-1 After completion callback invoked on Transaction synchronization: ... Instance of HotelSearchingAction 13:28:34,260 http--127.0.0.1-8080-2 Acquired lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3effb100 [State = 1, empty queue][Locked by 0:ffff7f000001:20b3094f:4f9e7717:48] 13:28:34,261 http--127.0.0.1-8080-2 Registered tx synchronization for tx: 0:ffff7f000001:20b3094f:4f9e7717:48 associated with HotelSearchingAction 13:28:34,266 http--127.0.0.1-8080-2 HotelSearchAction.isNextPageAvailable called 13:28:34,267 http--127.0.0.1-8080-2 Released Seam SynchronizationInterceptor hotelSearch lock 13:28:34,270 http--127.0.0.1-8080-1 Released lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3effb100[State = 1, empty queue][Locked by 0:ffff7f000001:20b3094f:4f9e7717:48] Version-Release number of selected component (if applicable): Seam2.2.5.EAP5 How reproducible: Almost always Steps to Reproduce: 1. deploy a migrated seam2.2 booking example 2. go to http://127.0.0.1:8080/seam-booking 3. login as gavin/foobar 4. enter "a" into the search field and wait (don't press or click anything else) 5. notice the error, or logout and try again Actual results: An error page with "Caused by javax.servlet.ServletException with message: "javax.el.ELException: /main.xhtml @36,71 value="#{hotelSearch.pageSize}": org.jboss.seam.core.LockTimeoutException: could not acquire lock on @Synchronized component: hotelSearch" or similar error message is displayed Expected results: No error Additional info: According to Stuart, the > The problem is that Seam 2 does its own locking outside the SFSB lock and >with a different scope. > >This means that if a thread access an EJB twice in the same transaction, after >the first invocation it will have the SFSB lock, but not the seam lock. A >second thread can then acquire the seam lock, which will then hit the EJB lock >and wait. When the first thread attempts its second invocation it will block >on the seam 2 interceptor and deadlock. > >In EE5 EJB's would throw an exception immediately on concurrent access, this >behaviour was changed in EE6. > >I think there are two real solutions: > > Add @AccessTimeout(0) to the EJB, this means it will throw an >ConcurrentAccessException immediately when this situation occurs > Patch seam to not use the synchronisation interceptor for stateful sessionbeans. Another workaround is to use @javax.ejb.TransactionAttribute(javax.ejb.TransactionAttributeType.NOT_SUPPORTED on the HotelSearchingAction.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Seam 2 does its own locking outside the SFSB lock. This means that if a thread accesses an EJB twice in the same transaction, a conflict will occur.
Work around for Seam 2.2 is suggested in JBPAPP-8869: "Add @AccessTimeout(0) to the EJB, this means it will throw an ConcurrentAccessException immediately when this situation occurs"
WFK 2.0 does not delivere Seam 2.2, however, these issues have already been documented in the EAP 6 release notes, so no need to duplicate each issue in WFk 2.0 release notes. However, we should include a pointer to the EAP 6 release notes to assist customers looking for Seam 2.2 bug information.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Seam 2 does its own locking outside the SFSB lock. This means that if a thread accesses an EJB twice in the same transaction, a conflict will occur.+Seam 2 does its own locking outside the SFSB lock. This means that if a thread accesses an EJB twice in the same transaction, a conflict will occur. The workaround for this issue is to add @AccessTimeout(0) to the EJB, which means it will throw an ConcurrentAccessException immediately when this situation occurs.
Marek Novotny <mnovotny> updated the status of jira JBPAPP-8905 to Resolved
Marek Novotny <mnovotny> made a comment on jira JBPAPP-8905 This is related to EJB 3.1 changes. Quoting Stuart's response: <snip> In EE5 EJB's would throw an exception immediately on concurrent access, this behaviour was changed in Java EE 6. I think there are two real solutions: 1. Add @AccessTimeout(0) to the EJB, this means it will throw an ConcurrentAccessException immediately when this situation occurs 2. Patch seam to not use the synchronisation interceptor for stateful session beans </snip> To allow compatible behaviour we can't do solution 2 and solution 1 is more like workaround. This applies only in case using Seam 2.2 on EAP6, EAP5 deployment still stays without changes.