Community
Participate
Working Groups
The job manager's scheduling rule may implement a client specific pessimistic locking. Modern concurrency access policies support the notion of optimistic locking where a timestamp is associated both with the transaction and the lock (scheduling rule) in order to determine if concurrent access has been conflicting. This may in turn yield some transactions (jobs) to fail if a concurrent access occurred. The job manager should therefore have the possibility to retry a job with a new timestamp/transaction if a previous write conflict occurred.
The Jobs API is about scheduling and isn't transactional, and there is no support for rollback nor replay. Optimistic locking works when there is very rare chance of interference between processes; in our primary usecases, dealing with incremental building, there is always interference between processes. I'm tempted to mark this as WONTFIX, but maybe someone else can think of a way to combine the approaches.
