docs(linkedin): apply consultant audit feedback, reorder by wave schedule, and sync NocoDB status
Deploy / build (push) Successful in 32s
Deploy / build (push) Successful in 32s
This commit is contained in:
1 parent
6f474b76e9
commit
bef57cbabb
15 files changed
+661
-715
No files matched your search
@@ -0,0 +1,63 @@
|
||||
# LinkedIn Draft & Consultant Review: The JPA @Version Field That Turns a Silent Lost Update Into an HTTP 409
|
||||
|
||||
> **文档性质**:从 `blog.hoelee.com` 改写并在 NocoDB 排期的 LinkedIn 生产级动态。
|
||||
> **发布状态**:`已通过外部顾问审阅 / NocoDB 已排期待发布`
|
||||
> **排期波次**:Wave 2 (纵深期) - 槽位 7 (拟发布日期: 2026-11-19 Thu)
|
||||
> **源文章**:https://blog.hoelee.com/posts/jpa-version-field-lost-update/
|
||||
> **系统标识**:`jpa-version-field-lost-update` | **分类**:`engineering`
|
||||
> **字数**:2248 chars (严格控制在 3,000 字符内)
|
||||
|
||||
---
|
||||
|
||||
## 一、 核心背景与铁律约束提示(供复核对照)
|
||||
|
||||
1. **求职画像契合(Senior 全栈/DevOps/AI 架构师)**:彻底脱敏“做生意的老板/小公司创始人”倾向;一切商业实战均转换为“生产系统架构、高可用交付与自动化运维”视角。
|
||||
2. **纯洁人设与零禁用词**:绝对禁止 `homelab`, `home lab`, `家用`, `小主机`, `玩具`, `折腾`, `玩票` 等词汇。必须使用 `the infrastructure I manage`, `my self-hosted production nodes`, `production host`。
|
||||
3. **第一人称单数**:统一使用单数 `I` / `我`,杜绝虚张声势的复数 `we`。
|
||||
4. **数据绝对保真**:所有数字、性能比率、吞吐提升、故障现象严禁凭空捏造。
|
||||
5. **OPSEC 安全脱敏**:无内部绝对路径(如 `D:/dev`),无真实私有内网 IP,公网 IP 必须转为文档保留地址。
|
||||
|
||||
---
|
||||
|
||||
## 二、 LinkedIn 拟发布动态文案(已按顾问意见修订)
|
||||
|
||||
```text
|
||||
Two users open the same record in a web application. Both make changes. Both click save.
|
||||
|
||||
User A saves first; the database updates and the API returns HTTP 200. User B saves two seconds later; the database overwrites User A's changes, and the API returns HTTP 200 again.
|
||||
|
||||
User A's work has completely vanished. No exception was logged, no alert fired, and both clients were explicitly told their save succeeded.
|
||||
|
||||
This is the classic **lost update problem**, and it remains one of the quietest data corruption defects in read-modify-write REST APIs.
|
||||
|
||||
Here is how I enforce end-to-end optimistic locking in Spring Boot (Java 21) services — and avoid the subtle trap that breaks most implementations:
|
||||
|
||||
1. Add `@Version` to the Entity
|
||||
Annotate an integer column with `@Version`. On every update, Hibernate automatically appends a version predicate to the SQL statement:
|
||||
`UPDATE posts SET title=?, body=?, version=version+1 WHERE id=? AND version=?`
|
||||
|
||||
2. Enforce Version in the API Contract (and Avoid the Managed-Entity Trap)
|
||||
Expose `version` in the read DTO and mandate it in the write payload (`UpdatePostRequest`).
|
||||
The classic trap: if you call `findById(id)` inside your `@Transactional` update method and only copy mutable fields (`title`, `body`) onto that freshly loaded entity, Hibernate uses the database's current version rather than the client's stale version — silently bypassing optimistic locking. You must explicitly verify the client's submitted version against the loaded entity (or map the request version onto a detached state) before flushing.
|
||||
|
||||
3. Translate Concurrency Failures into Clean HTTP 409 Contracts
|
||||
When concurrent requests race, Hibernate detects 0 rows updated and throws `OptimisticLockException` (wrapped by Spring as `ObjectOptimisticLockingFailureException`). A centralized `@RestControllerAdvice` translates this into an `HTTP 409 Conflict`:
|
||||
`{ "error": "CONFLICT", "message": "Record was modified by another transaction. Please reload and reapply your changes." }`
|
||||
|
||||
An explicit HTTP 409 is infinitely better than a deceptive HTTP 200.
|
||||
|
||||
How does your backend architecture handle concurrent writes and state conflicts across distributed clients?
|
||||
|
||||
Write-up: https://blog.hoelee.com/posts/jpa-version-field-lost-update/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、 外部顾问审阅评估反馈单与归档记录
|
||||
|
||||
- [x] **审阅结论**:需微调(已更新修订稿)
|
||||
- **1. 诊断与修改批注**:职级拔高:补充 JPA 托管实体自动覆盖版本号的深坑解析,展现 Senior 级代码审查功底。
|
||||
- **2. NocoDB 归档记录**:
|
||||
- Candidate Key: `cand:jpa-version-field-lost-update` (Status: `APPROVED`, Priority: `HIGH`)
|
||||
- Draft Key: `cand:jpa-version-field-lost-update:v1` (Status: `APPROVED`)
|
||||
- 拟定发布节奏:每周 2 篇(周二/周四),平稳推进 5 周。
|
||||
Reference in new issue
Block a user