Skip to content

DefaultLockRepository fails to acquire lock on Oracle. #3129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
cppwfs opened this issue Dec 18, 2019 · 2 comments · Fixed by #3133
Closed

DefaultLockRepository fails to acquire lock on Oracle. #3129

cppwfs opened this issue Dec 18, 2019 · 2 comments · Fixed by #3133
Labels
in: jdbc type: enhancement
Milestone
5.3.0.M1

Comments

@cppwfs
Copy link
Contributor

cppwfs commented Dec 18, 2019

The acquire method in the DefaultLockRepository fails to acquire the lock after the initial insert of the entry in the %s_LOCK table.
https://github.com/spring-projects/spring-integration/blob/master/spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/lock/DefaultLockRepository.java#L159-L166

i.e. the template update returns 0 for the row count updated even though there is an entry in the database. And thus the insert is called a second time which throws a DuplicateKeyException

This behavior only shows up in Oracle. I've tested on H2, MySql and Postgresql.

  • We have wrapped the code in a TransactionTemplate on the Spring Cloud Task side and the same result occurred.
  • Also tried to use the OracleXADataSource and this also did not work.

Here is a sample application that replicates the behavior: https://github.com/cppwfs/acquirelockfailtest
And it was tested using oracle/database:12.2.0.1-se2

A little more info can be found here: spring-cloud/spring-cloud-task#640
@cppwfs
Copy link
Contributor Author

cppwfs commented Dec 18, 2019

Let's chat when you get a chance.

@cppwfs cppwfs mentioned this issue Dec 18, 2019
Closed
@artembilan
Copy link
Member

See the workaround for current applications: spring-cloud/spring-cloud-task#640 (comment)

The fix for this issue will contain a changed schema for all the table in Oracle scripts.

@artembilan artembilan added this to the 5.3.0.M1 milestone Dec 26, 2019
artembilan added a commit to artembilan/spring-integration that referenced this issue Dec 26, 2019
@artembilan
spring-projectsGH-3129: Use VARCHAR2 for non-fixed strings
94afdae 
Fixes spring-projects#3129

The `CHAR` type in Oracle is for fixed length values.
If the value is not of expected length it is padded with whitespaces.
This causes wrong assumptions when we perform queries against tables.

* Change the `CHAR` into a `VARCHAR2` in those tables for Oracle
where we don't have values with a fixed length.
In fact only `MESSAGE_ID` comes with always fixed length as `36`
because it is fully based on the `UUID`
@artembilan artembilan mentioned this issue Dec 26, 2019
Merged
garyrussell pushed a commit that referenced this issue Dec 26, 2019
@artembilan @garyrussell
GH-3129: Use VARCHAR2 for non-fixed strings (#3133)
1a9fb83 
Fixes #3129

The `CHAR` type in Oracle is for fixed length values.
If the value is not of expected length it is padded with whitespaces.
This causes wrong assumptions when we perform queries against tables.

* Change the `CHAR` into a `VARCHAR2` in those tables for Oracle
where we don't have values with a fixed length.
In fact only `MESSAGE_ID` comes with always fixed length as `36`
because it is fully based on the `UUID`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
in: jdbc type: enhancement
Projects
None yet
Milestone
5.3.0.M1
Development

Successfully merging a pull request may close this issue.

GH-3129: Use VARCHAR2 for non-fixed strings artembilan/spring-integration
2 participants
@cppwfs @artembilan