Changes should only become visible when the transaction commits and all its changes are made durable. This approach places the responsibility of synchronization and deadlock detection on the Castor persistence engine, easing the life of the developer. Locking Modes Concurrent access requires use of locking to synchronize two transactions attempting to work with the same object. The locking mechanism has to take into account several possible use of objects, as well as help minimize database access through caching and is-modified checking. The shared mode is the default for all objects, unless otherwise specified in the mapping file.
Shared mode allows two transactions to read the same record at the same time.
Each transaction will get it's own view of the record as a separate object, to prevent in-memory changes from conflicting with each other. However, the values loaded from the database are the same for both transactions. When transactions query different objects or query the same objects but for read-only purposes, shared access provides the most efficient means of access in terms of performance, utilizing record caching and eliminating lock contention. For example, when each transaction retrieves a different Customer record and all transactions retrieved the same set of Department records but hardly ever change them, both Customer and Department should be declared as having a shared lock. However, when two transactions attempt to access the same object, modify it, and commit the changes, a concurrency conflict will occurs.