jdaugherty commented on PR #16344:
URL: https://github.com/apache/grails-core/pull/16344#issuecomment-5679976259
For the method naming, I settled on lockLatest() because it expresses the
intended difference from existing lock(): acquire the lock using freshly loaded
database state, rather than require the previously loaded version to remain
current.
The reasoning was:
- lock(refresh: true) was initially my preference. It was concise and fit
GORM’s named-option style. But it collided with the existing static
lock(Serializable id) method. Groovy allows static calls through an instance,
and map literals implement both Map and Serializable. I reproduced Groovy 5.1.2
choosing the static overload and treating the options map as an ID.
- Fixing that collision would have changed an existing signature. Broadening
static lock(Serializable) to lock(Object) resolved dispatch, but introduced a
binary-compatibility change. A distinct method name avoided that entirely.
- pessimisticLock() didn’t distinguish the behavior. Existing lock() already
acquires a pessimistic lock. The new behavior is reloading state and version
while acquiring it.
- refreshAndLock(), lockAndRefresh(), and similar names were explicit but
cumbersome. They also could suggest two sequential operations, whereas the
implementation uses Hibernate’s refresh-with-lock operation.
- refresh(lock: true) was technically viable, but lockLatest() better
matched the caller’s intent: “lock this entity so I can work from its current
database state.”
The resulting API keeps the distinction straightforward:
book.lock() // Lock while retaining loaded state and checking
its version.
book.lockLatest() // Reload state and version under a pessimistic
write lock.
“Latest” describes the intent, not an unconditional guarantee: database
isolation rules still apply. The documentation explicitly states that
lockLatest() discards unflushed changes, requires an active transaction, and
can still fail because of timeouts, deadlocks, or serialization conflicts.
I'm still open to changing the method signature, but that would require a
major release and I was hoping to have the change sooner than 9.0.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
