Usually in a domain model, you'll have objects, and those objects will have properties that are mutable and properties that are immutable - for instance, a instance id/name will be immutable, while some other properties (specially properties that depend on relationships with other objects) can vary in the lifetime of an object

So, in the usual scenario where multiple clients are accessing the same data store, your ORM tool will usually model columns as properties and relationships as lists, in the mutual understanding that any mutable property might be outdated in the client - that is, they only represent caches of the values of the properties.

However, in many circumstances, one wants to do an operation that might require the actual state of the mutable properties, otherwise the operation might fail or produce data corruption, so in those cases you'll attempt a lock in the row in question, and if the row has already changed then you cancel or abort. In any case, the operation is done off the client application.

At some point I have to ask a question (oddly enough, its turning out to be surprising hard!), so I guess the question would be: is there any scenario where it's useful to keep mutable properties cached in domain objects for anything else than informational purposes? After all, if there are relationships that we care for, say we want to traverse the neighbours of some object, we'll want to do that with their real (not cached) states, which would involve a database transaction, or some other means to do the process atomically (maybe map reduce?).

1 Answer 1


Ideally, you want to minimize entity state synchronization to avoid unnecessary DB access, so in cases where you don't have to worry too much about resource conflicts, optimistic locking works well.

There are three phases to optimistic locking:

  • Begin: Record a timestamp marking the transaction's beginning.
  • Modify: Read and write database values.
  • Validate: Check whether other transactions have modified data that this transaction has used (read or wrote). Always check transactions that completed after this transaction's start time. Optionally, check transactions that are still active at validation time.
  • Commit/Rollback: If there is no conflict, make all changes part of the official state of the database. If there is a conflict, resolve it, typically by aborting the transaction, although other resolution schemes are possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.