title: Spring JPA Lock
body: <p>I am really insecure when it comes to locking in spring jpa.<br>
  So please consider this question as an clarification. I really hope I understood it correct, but my english is not so good for understanding complex blog posts.<br>
  So this is what I think I got from some articles:    </p>
  
  <p>There are two basic types of locking:  </p>
  
  <ul>
  <li><strong>optimistic</strong> should be used when less write operation are planned. read operation will not lock an object.<br>
  For example: You have an "money balance" float in an entity with an optimistic lock. Now two processes read this value and use it for calculating and stuff. One of them now changes the value and writes it to the database with an update. No error to this point.<br>
  But now the other process also changes the value and wants to update it. Now there is an error. This only happened because of the second update.<br>
  If the second process would have deleted the instance, nothing would have happend.  </li>
  <li><strong>pessimistic</strong> should be used when much write operation are planned. read operation will lock an object.<br>
  For example: You have an "money balance" float in an entity with an pessimistic lock. One process reads the data/value with "findOne".<br>
  After this, an other process wants to read the data as well, what would be possible with an optimistic lock, but with the pessimistic lock he must now wait (no error, just wait).<br>
  When process 1 is ready (changing the value and updating it), process 2 can go on.  </li>
  </ul>
  
  <p>First Questions: Is this correct so far? And when I now want to test this knollage, I can choose between this LockModeType's:  </p>
  
  <ul>
  <li>OPTIMISTIC  </li>
  <li>OPTIMISTIC_FORCE_INCREMENT  </li>
  <li>PESSIMISTIC_READ  </li>
  <li>PESSIMISTIC_WRITE  </li>
  <li>PESSIMISTIC_FORCE_INCREMENT  </li>
  </ul>
  
  <p>Why are there now so many sub-locks and what do they do? When "OPTIMISTIC" is the optimistic lock from the top I tried to understand, then what is "OPTIMISTIC_FORCE_INCEMENT"?<br>
  And what does an version update has to do with this? (or the <code>@version</code>?)  </p>
  
  <p>Going on:<br>
  There are three basic uses of lock in Spring jpa:  </p>
  
  <ol>
  <li><p>on a normal column, for example:  </p>
  
  <pre><code>@Entity
  public class PersonEntity {
      @Id
      @GeneratedValue(strategy = GenerationType.AUTO)
      private Long id;
  
      @Lock(LockModeType.PESSIMISTIC_WRITE)
      private String name;
  }  
  </code></pre></li>
  <li><p>on a foreign key to an other table, for example:  </p>
  
  <pre><code>@Entity
  public class PersonEntity {
      @Id
      @GeneratedValue(strategy = GenerationType.AUTO)
      private Long id;
  
      @Lock(LockModeType.PESSIMISTIC_WRITE)
      @OneToOne
      private Group group;
  }  
  </code></pre></li>
  <li><p>on a table inside a repository, for example:  </p>
  
  <pre><code>interface PersonRepository extends Repository&lt;Person, Long&gt; {
      @Lock(LockModeType.PESSIMISTIC_WRITE)
      Person findOne(Long id);
  }  
  </code></pre></li>
  </ol>
  
  <p>Locking a Entity directly with  </p>
  
  <pre><code>@Entity
  @Lock(LockModeType.PESSIMISTIC_WRITE)
  public class PersonEntity { }
  </code></pre>
  
  <p>is not possible. Therefore you can use 3 (locking inside a repository).  </p>
  
  <p>Second Question: Is this correct? Did I forgot about a use of a locking?  </p>
  
  <p>Going on:<br>
  The idea behind locking is, that other methods/processes have to wait until a lock is released (except by the optimistic lock, here a error is thrown).<br>
  The Lock is there as long as the instance/object is active or until the next commit.<br>
  There are two main possibilities to unlock an object:  </p>
  
  <ol>
  <li><p>Within an transaction: In this full method the lock is active. But when the return comes, the lock will be removed.  </p>
  
  <pre><code>@Transactional
  public void test(){
      System.out.println("start, but not locked yet");
      PersonEntity person1 = personRepository.findOne(1L); // locks this person or must wait, when locked
      System.out.println("now locked");
      // do something
      return true; // now the lock will be deleted -&gt; unlocked again
  }  
  </code></pre></li>
  <li><p>until the object is deleted: The data will be locked when the object is selected, and the data will be unlocked when the object is deleted.  </p>
  
  <pre><code>public void test(){
      System.out.println("start, but not locked yet");
      PersonEntity person1 = personRepository.findOne(1L); // locks this person or must wait, when locked
      System.out.println("now locked");
      // do something
      person1 = null; // now the lock will be deleted -&gt; unlocked again
      System.out.println("not locked anymore");
      // do something more
      return true;
  }  
  </code></pre></li>
  </ol>
  
  <p>Third Questions: is this correct so far? Does this function really can wait then the data is locked? Can an lock really be deleted when the object is set to <code>null</code>?  </p>
  
  <p>Last words:<br>
  I really hope I will not annoy somebody. But like I said: it is really difficult for me to understand such complex structures in the english language :(<br>
  So thanks a lot for help in any form :) I really appreciate any little help. regardless of whether you give me links for more understanding or answering my questions directly :)</p>