title: Spring Integration JDBC lock failure
body: <p>I don't understand the behavior for distributed locks obtained from a JdbcLockRegistry.</p>
  
  <pre><code>@Bean
  public LockRepository lockRepository(DataSource datasource) {
      return new DefaultLockRepository(datasource);
  }
  
  @Bean
  public LockRegistry lockRegistry(LockRepository repository) {
      return new JdbcLockRegistry(repository);
  }
  </code></pre>
  
  <p>My project is running upon PostgreSQL and Spring Boot version is 2.2.2
  And this is the demonstration use case :</p>
  
  <pre><code>@GetMapping("/isolate")
  public String isolate() throws InterruptedException {
      Lock lock = registry.obtain("the-lock");
      if (lock.tryLock(10, TimeUnit.SECONDS)) {   // close
          try {
              Thread.sleep(30 * 1000L);
          } finally {
              lock.unlock();                      // open
          }
      } else {
          return "rejected";
      }
      return "acquired";
  }
  </code></pre>
  
  <p>NB: that use case works when playing with Hazelcast distributed locks.</p>
  
  <p>The observed behavior is that a first lock is duly registered in database through a call to the API on a first instance.
  Then, within 30 seconds, a second on is requested on a different instance (other port), and it's updating the existing int_lock table's line (client_id changes) instead of failing. So the first endpoint delivers after 30 seconds (no unlock failure), and the second endpoint is delivering after its own period of 30 seconds. There is no mutual exclusion.</p>
  
  <p>These are the logs for a single acquisition :</p>
  
  <pre><code>Trying to acquire lock...
  Executing prepared SQL update
  Executing prepared SQL statement [DELETE FROM INT_LOCK WHERE REGION=? AND LOCK_KEY=? AND CREATED_DATE&lt;?]
  Executing prepared SQL update
  Executing prepared SQL statement [UPDATE INT_LOCK SET CREATED_DATE=? WHERE REGION=? AND LOCK_KEY=? AND CLIENT_ID=?]
  Executing prepared SQL update
  Executing prepared SQL statement [INSERT INTO INT_LOCK (REGION, LOCK_KEY, CLIENT_ID, CREATED_DATE) VALUES (?, ?, ?, ?)]
  Processing...
  Executing prepared SQL update
  Executing prepared SQL statement [DELETE FROM INT_LOCK WHERE REGION=? AND LOCK_KEY=? AND CLIENT_ID=?]
  </code></pre>
  
  <p>It sounds strange that acquisition process begins with DELETE, though...
  I've tried to set a constant client id for the DefaultLockRepository, without improvement.
  Does anyone have a clue of understanding of how to fix this ? Thx for any help.</p>