Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 818481

Summary:	Seam2.2 on EAP6 deadlock between org.jboss.seam.core.SynchronizationInterceptor and stateful component instance EJB lock during an ajax request.
Product:	[Retired] JBoss Enterprise WFK Platform 2	Reporter:	Marek Schmidt <maschmid>
Component:	Seam	Assignee:	Marek Novotny <mnovotny>
Status:	CLOSED CANTFIX	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	2.0.0.GA	CC:	rnewton
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	Seam2.2
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 15:32:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marek Schmidt 2012-05-03 08:33:32 UTC

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 04:19:50 UTC

    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 06:40:08 UTC

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 15:32:12 UTC

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 06:19:54 UTC

    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 08:15:45 UTC

Marek Novotny <mnovotny> updated the status of jira JBPAPP-8905 to Resolved

Comment 7 JBoss JIRA Server 2012-07-18 08:15:45 UTC

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.