jakartaee / jakartaee/persistence
revise section 3.9 Locking and Concurrency
- Dominant language
- Java
- Stars
- 267
- Forks
- 78
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 13
Description
When I went through reworking chapter 3, I deliberately left section 3.9 out of the review because I knew it deserved its own careful attention after M1.
- I think this section could be written in a somewhat more readable way.
- I don't quite understand why it says that we assume RC isolation but then talks a lot about dirty reads which are impossible in RC and has nothing to say about lost updates, which *are* possible.
- I also think the spec needs to clarify that what JPA calls `LockModeType.OPTIMISTIC` is absolutely **not** what most people call "optimistic locking". The thing usually called "optimistic locking" prevents lost updates and allows non-repeatable reads.
I also wonder if we should say something more about what happens if the database itself is _not_ in RC.
Contributor guide
Research direction
Start by reading chapter 3, section 3.9, Locking and Concurrency, and compare its treatment of read-committed isolation, dirty reads, lost updates, and JPA lock terminology. Done means the section is more readable and clearly explains these behaviors, including what happens when the database is not using read committed isolation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100