Skip to content
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

optimistic LockModes #201

Closed
gavinking opened this issue May 27, 2020 · 4 comments · Fixed by #329
Closed

optimistic LockModes #201

gavinking opened this issue May 27, 2020 · 4 comments · Fixed by #329
Assignees
@gavinking
Labels
enhancement New feature or request
Milestone
FIRST CUT

Comments

@gavinking
Copy link
Member

The LockMode types OPTIMISTIC and OPTIMISTIC_FORCE_INCREMENT passed to lock() are used to explicitly request a version check or version increment during the before completion phase of the transaction (not at flush time, if I understand correctly).

Since we don't really even have a well-defined transaction completion phase at this stage, I'm not going to add them now.

Also I doubt these are very widely-used.
@gavinking gavinking mentioned this issue May 27, 2020
Closed
@gavinking gavinking added the enhancement New feature or request label May 27, 2020
@Sanne Sanne mentioned this issue Jun 30, 2020
Closed
@gavinking
Copy link
Member Author

gavinking commented Jun 30, 2020 •
edited
Loading

Folks, please note that this issue isn’t saying that we don’t support optimistic locking! It’s a very specific issue with passing certain lock modes explicitly to the lock() method, a feature which didn’t even exist in Hibernate and JPA prior to JPA 2.

@gavinking
Copy link
Member Author

gavinking commented Aug 23, 2020 •
edited
Loading

So fixing this issue requires adding reactive implementations of(at least):

  • DefaultPostLoadEventListener, and its helpers
  • EntityVerifyVersionProcess and EntityIncrementVersionProcess, which will call ReactiveEntityPersister.lockReactive() and reactiveGetDatabaseSnapshot().

This doesn't look so bad.

gavinking added a commit to gavinking/hibernate-reactive that referenced this issue Aug 23, 2020
@gavinking
support for OPTIMISTIC + OPTIMISTIC_FORCE_INCREMENT LockModes
90e200e 
These LockModes force a version check or upgrade right at the
end of the transaction.

This required building infrastructure for reactive before/after
transaction completion events.

Fixes hibernate#201
@gavinking gavinking mentioned this issue Aug 23, 2020
Merged
gavinking added a commit to gavinking/hibernate-reactive that referenced this issue Aug 23, 2020
@gavinking
support for OPTIMISTIC + OPTIMISTIC_FORCE_INCREMENT LockModes
8dabf8b 
These LockModes force a version check or upgrade right at the
end of the transaction.

This required building infrastructure for reactive before/after
transaction completion events.

Fixes hibernate#201
@gavinking gavinking added this to the FIRST CUT milestone Aug 23, 2020
@gavinking gavinking self-assigned this Aug 23, 2020
@gavinking
Copy link
Member Author

gavinking commented Aug 23, 2020 •
edited
Loading

This is done for find() in #329, but still not for lock().

(It's also not done for refresh(), but if I'm not mistaken core doesn't support these lock modes in refresh() either, so I'm not sure I care.)

gavinking added a commit to gavinking/hibernate-reactive that referenced this issue Aug 23, 2020
@gavinking
support for OPTIMISTIC + OPTIMISTIC_FORCE_INCREMENT LockModes
4b4ce5e 
These LockModes force a version check or upgrade right at the
end of the transaction.

This required building infrastructure for reactive before/after
transaction completion events.

Fixes hibernate#201
gavinking added a commit that referenced this issue Aug 24, 2020
@gavinking
support for OPTIMISTIC + OPTIMISTIC_FORCE_INCREMENT LockModes
0e99e99 
These LockModes force a version check or upgrade right at the
end of the transaction.

This required building infrastructure for reactive before/after
transaction completion events.

Fixes #201
@gavinking
Copy link
Member Author

Done, finally!

DavideD added a commit to DavideD/hibernate-reactive that referenced this issue Dec 12, 2024
@DavideD
[hibernate#1895] Upgrade Hibernate ORM to 7.0.0.Beta3
cfb25af 
Notes:

* Fix hibernate#201: ReactiveIdentifierGenerator must extends Generator
* The Hibernate Gradle plugin has not been released yet, so we keep it to 7.0.0.Beta2
* XML sql data type is not supported: eclipse-vertx/vertx-sql-client#1475
* Stop using `org.hibernate.dialect.DialectDelegateWrapper` (not
  required anymore)
* Remove `ReactiveOracleSqlAstTranslator` (not required anymore)
* Only process parameters for native queries. See hibernate#2012
* Remove `ReactiveIdentifierGeneratorFactory`: the service doesn't exist
  anymore in ORM
* Add `persist(String, Object)` to the session
* Remove test for `hibernate.create_empty_composites.enabled`: see [HHH-18222](https://hibernate.atlassian.net/browse/HHH-18222)
* Contains some clean ups
* There are still some issues with embeddable mapped as JSON and native queries: See hibernate#1999
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gavinking gavinking

Labels
enhancement New feature or request
Projects
None yet
Milestone
FIRST CUT
Development

Successfully merging a pull request may close this issue.

support for OPTIMISTIC + OPTIMISTIC_FORCE_INCREMENT LockModes gavinking/hibernate-reactive
1 participant
@gavinking