Bug 1316498 - OData - if PUT fails, next update request fails because table in DB is still locked
OData - if PUT fails, next update request fails because table in DB is still ...
Status: CLOSED CURRENTRELEASE
Product: JBoss Data Virtualization 6
Classification: JBoss
Component: Teiid (Show other bugs)
6.3.0
Unspecified Unspecified
unspecified Severity unspecified
: ER2
: 6.3.0
Assigned To: Van Halbert
Juraj Duráni
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-10 06:11 EST by Juraj Duráni
Modified: 2016-08-24 07:42 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-24 07:42:55 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 TEIID-4057 Major Closed OData - if PUT fails, next update request fails because table in DB is still locked 2016-06-15 08:22 EDT

  None (edit)
Description Juraj Duráni 2016-03-10 06:11:46 EST
Description of problem:
I can see (from the log) that processing of PUT request is as follows:
1. select record from table
2. delete record
3. parse entity from HTTP request
4. insert new record

But if e.g. step 3 fails, Teiid cancels transaction and returns error. In my opinion, parsing of the entity should be the first step (or at least right after select).
What happen here is, that DELETE statement creates transaction and locks the table. But the transaction is not canceled immediately after cancel request [1]. This causes that no other query can succeed, because of lock on the table (EAP uses connection pool and does not close connections immediately and therefore open connection has still one transaction in active state).

*Note:* We use H2 database for testing purpose. But I think that this could happen with any DB. Anyway, parsing of the entity should not be performed after delete. 

[1]
09:35:33,937 DEBUG [org.teiid.TRANSPORT] (New I/O worker #1) Channel closed
09:40:31,430 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff7f000001:113c3cbe:56e131a7:e in state  RUN
09:40:31,438 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff7f000001:113c3cbe:56e131a7:e
Comment 1 JBoss JIRA Server 2016-03-14 10:15:11 EDT
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-4057 to Coding In Progress
Comment 2 JBoss JIRA Server 2016-03-14 15:09:29 EDT
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-4057 to Resolved
Comment 3 JBoss JIRA Server 2016-06-15 08:22:11 EDT
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-4057 to Closed

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