diff --git a/jOOQ-website/src/main/resources/manual-2.5.xml b/jOOQ-website/src/main/resources/manual-2.5.xml index 04a1a27f7e..c351627b37 100644 --- a/jOOQ-website/src/main/resources/manual-2.5.xml +++ b/jOOQ-website/src/main/resources/manual-2.5.xml @@ -159,7 +159,7 @@ exists(); max(); min(); val(); inline(); // correspond to Factory.exists(); Fact BOOK.TITLE, AUTHOR.LAST_NAME // correspond to com.example.generated.Tables.BOOK.TITLE, com.example.generated.Tables.BOOK.TITLE // Whenever you see "create" being used in Java code, assume that this is an instance of org.jooq.impl.Factory: -Factory create = new Factory(SQLDialect.ORACLE, connection);]]> +Factory create = new Factory(connection, SQLDialect.ORACLE);]]>

Settings

@@ -5264,7 +5264,7 @@ create.executeUpdate(book);]]>

books = coAuthor.fetchBookListByCoAuthorId();]]>
Optimistic locking - + +

Optimistic locking handled by jOOQ

+

+ jOOQ allows you to perform operations using optimistic locking. You can immediately take advantage of this feature by activating the relevant . Without any further knowledge of the underlying data semantics, this will have the following impact on store() and delete() methods: +

+
    +
  • INSERT statements are not affected by this Setting flag
  • +
  • Prior to UPDATE or DELETE statements, jOOQ will run a statement, pessimistically locking the record for the subsequent UPDATE / DELETE
  • +
  • The data fetched with the previous SELECT will be compared against the data in the record being stored or deleted
  • +
  • An is thrown if the record had been modified in the mean time
  • +
  • The record is successfully stored / deleted, if the record had not been modified in the mean time.
  • +
+

+ The above changes to jOOQ's behaviour are transparent to the API, the only thing you need to do for it to be activated is to set the Settings flag. Here is an example illustrating optimistic locking: +

+ + + +

Optimised optimistic locking using TIMESTAMP fields

+

+ If you're using jOOQ's , you can take indicate TIMESTAMP or UPDATE COUNTER fields for every generated table in the . Let's say we have this table: +

+ + + +

+ The MODIFIED column will contain a timestamp indicating the last modification timestamp for any book in the BOOK table. If you're using jOOQ and it's , jOOQ will then generate this TIMESTAMP value for you, automatically. However, instead of running an additional statement prior to an UPDATE or DELETE statement, jOOQ adds a WHERE-clause to the UPDATE or DELETE statement, checking for TIMESTAMP's integrity. This can be best illustrated with an example: +

+ + + +

+ As before, without the added TIMESTAMP column, optimistic locking is transparent to the API. +

+ +

Optimised optimistic locking using VERSION fields

+

+ Instead of using TIMESTAMPs, you may also use numeric VERSION fields, containing version numbers that are incremented by jOOQ upon store() calls. +

+ +

+ Note, for explicit pessimistic locking, please consider the manual's section about the . For more details about how to configure TIMESTAMP or VERSION fields, consider the manual's section about . +

+
Batch execution - + +

Batch CRUD operations

+

+ When inserting, updating, deleting a lot of records, you may wish to profit from JDBC batch operations, which can be performed by jOOQ. These are available through jOOQ's as shown in the following example: +

+ + books = create.fetch(BOOK); + +// Modify the above books, and add some new ones: +modify(books); +addMore(books); + +// Batch-update and/or insert all of the above books +create.batchStore(books);]]> + +

+ Internally, jOOQ will render all the required SQL statements and execute them as a regular . +

+
@@ -6504,7 +6599,7 @@ public class BookDao extends DAOImpl {