Bug 818481 - Seam2.2 on EAP6 deadlock between org.jboss.seam.core.SynchronizationInterceptor and stateful component instance EJB lock during an ajax request.
Seam2.2 on EAP6 deadlock between org.jboss.seam.core.SynchronizationIntercept...
Status: CLOSED CANTFIX
Product: JBoss Enterprise WFK Platform 2
Classification: JBoss
Component: Seam (Show other bugs)
2.0.0.GA
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Marek Novotny
Seam2.2
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-03 04:33 EDT by Marek Schmidt
Modified: 2012-07-18 04:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Seam 2.2.5.EAP5 (from EAP5.1.2), EAP 6.0.0.ER6
Last Closed: 2012-06-18 11:32:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBPAPP-8905 Critical Resolved Seam2.2 on EAP6 deadlock between org.jboss.seam.core.SynchronizationInterceptor and stateful component instance EJB lock... 2013-07-23 04:52:13 EDT

  None (edit)
Description Marek Schmidt 2012-05-03 04:33:32 EDT
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.
Comment 2 Rebecca Newton 2012-05-14 00:19:50 EDT
    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.
Comment 3 Marek Novotny 2012-05-14 02:40:08 EDT
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"
Comment 4 mark yarborough 2012-06-18 11:32:12 EDT
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.
Comment 5 Rebecca Newton 2012-06-20 02:19:54 EDT
    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.
Comment 6 JBoss JIRA Server 2012-07-18 04:15:45 EDT
Marek Novotny <mnovotny@redhat.com> updated the status of jira JBPAPP-8905 to Resolved
Comment 7 JBoss JIRA Server 2012-07-18 04:15:45 EDT
Marek Novotny <mnovotny@redhat.com> 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.

Note You need to log in before you can comment on or make changes to this bug.