You have to inflate your cache anew from DB in every transaction.
You don't have any data when you start.
Sure, that's unavoidable if you want to do optimistic locking.
You can do optimistic locking with cached data just as well. It
doesn't have to come from the same transaction as your update.
That's the whole point of it.
Agreed for the records that are being written back.

However, there are records that have indirect dependencies. Stuff like updates to child records of which the parent record has gone away. Constraints that are not (portably or easily) expressible, such as rows covering contiguous ranges in their START_PERIOD and END_PERIOD fields. Configuration data that describes valid values, process A reduces the valid range, process B has the configuration in cache and validates against a stale configuration.
This kind of stuff can be handled by either reloading everything on every application transaction. That's Hibernate's standard mode of operation (if you don't use a second-level cache, which is the default). Or by explicit coding. Or by letting application programmers specify each and every data dependency, and having the ORM detect changes not just in the records being updated but also changes in all records that these updates might depend on.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 38 of 39 | next ›
Discussion Overview
groupuser @
postedMar 28, '12 at 8:27a
activeApr 10, '12 at 3:18p



site design / logo © 2022 Grokbase