set transaction timeouts and retry limits in the example class scheduling tutorial

Resolves #882: Consider setting timeouts in example code

documentation/sphinx/source/class-scheduling-go.rst

@@ -226,6 +226,11 @@ Without the :func:`Transact` method, signup would look something like:
 
 Furthermore, this version can only be called with a ``Database``, making it impossible to compose larger transactional functions by calling one from another.
 
+Note that by default, the operation will be retried an infinite number of times and the transaction will never time out. It is therefore recommended that the client choose a default transaction retry limit or timeout value that is suitable for their application. This can be set either at the transaction level using the ``SetRetryLimit`` or ``SetTimeout`` transaction options or at the database level with the ``SetTransactionRetryLimit`` or ``SetTransactionTimeout`` database options. For example, one can set a one minute timeout on each transaction and a default retry limit of 100 by calling::
+
+    db.Options().SetTransactionTimeout(60000)  // 60,000 ms = 1 minute
+    db.Options().SetRetryLimit(100)
+
 Making some sample classes
 --------------------------
 
@@ -663,6 +668,8 @@ Here's the code for the scheduling tutorial:
   func main() {
     fdb.MustAPIVersion(610)
     db := fdb.MustOpenDefault()
+    db.Options().SetTransactionTimeout(60000)  // 60,000 ms = 1 minute
+    db.Options().SetTransactionRetryLimit(100)
 
     schedulingDir, err := directory.CreateOrOpen(db, []string{"scheduling"}, nil)
     if err != nil {

documentation/sphinx/source/class-scheduling-java.rst

@@ -154,6 +154,11 @@ is equivalent to something like:
 
 If instead you pass a :class:`Transaction` for the :class:`TransactionContext` parameter, the transaction will be used directly, and it is assumed that the caller implements appropriate retry logic for errors. This permits functions using this pattern to be composed into larger transactions.
 
+Note that by default, the operation will be retried an infinite number of times and the transaction will never time out. It is therefore recommended that the client choose a default transaction retry limit or timeout value that is suitable for their application. This can be set either at the transaction level using the ``setRetryLimit`` or ``setTimeout`` transaction options or at the database level with the ``setTransactionRetryLimit`` or ``setTransactionTimeout`` database options. For example, one can set a one minute timeout on each transaction and a default retry limit of 100 by calling::
+
+    db.options().setTransactionTimeout(60000);  // 60,000 ms = 1 minute
+    db.options().setRetryLimit(100);
+
 Making some sample classes
 --------------------------
 
@@ -438,6 +443,8 @@ Here's the code for the scheduling tutorial:
     static {
       fdb = FDB.selectAPIVersion(610);
       db = fdb.open();
+      db.options().setTransactionTimeout(60000);  // 60,000 ms = 1 minute
+      db.options().setRetryLimit(100);
     }
 
     // Generate 1,620 classes like '9:00 chem for dummies'

documentation/sphinx/source/class-scheduling-ruby.rst

@@ -123,6 +123,11 @@ is equivalent to something like:
 
 If instead you pass a :class:`Transaction` for the ``db_or_tr`` parameter, the transaction will be used directly, and it is assumed that the caller implements appropriate retry logic for errors. This permits functions using this pattern to be composed into larger transactions.
 
+Note that by default, the operation will be retried an infinite number of times and the transaction will never time out. It is therefore recommended that the client choose a default transaction retry limit or timeout value that is suitable for their application. This can be set either at the transaction level using the ``set_retry_limit`` or ``set_timeout`` transaction options or at the database level with the ``set_transaction_retry_limit`` or ``set_transaction_timeout`` database options. For example, one can set a one minute timeout on each transaction and a default retry limit of 100 by calling::
+
+    @db.options.set_transaction_timeout(60000)  # 60,000 ms = 1 minute
+    @db.options.set_retry_limit(100)
+
 Making some sample classes
 --------------------------
 
@@ -379,6 +384,8 @@ Here's the code for the scheduling tutorial:
     # ['class', class_name] = seats_left
 
     @db = FDB.open
+    @db.options.set_transaction_timeout(60000)  # 60,000 ms = 1 minute
+    @db.options.set_transaction_retry_limit(100)
 
     def add_class(db_or_tr, c)
         db_or_tr.transact do |tr|

documentation/sphinx/source/class-scheduling.rst

@@ -133,6 +133,11 @@ is equivalent to something like::
 
 If instead you pass a :class:`Transaction` for the ``tr`` parameter, the transaction will be used directly, and it is assumed that the caller implements appropriate retry logic for errors. This permits transactionally decorated functions to be composed into larger transactions.
 
+Note that by default, the operation will be retried an infinite number of times and the transaction will never time out. It is therefore recommended that the client choose a default transaction retry limit or timeout value that is suitable for their application. This can be set either at the transaction level using the ``set_retry_limit`` or ``set_timeout`` transaction options or at the database level with the ``set_transaction_retry_limit`` or ``set_transaction_timeout`` database options. For example, one can set a one minute timeout on each transaction and a default retry limit of 100 by calling::
+
+    db.options.set_transaction_timeout(60000)  # 60,000 ms = 1 minute
+    db.options.set_retry_limit(100)
+
 Making some sample classes
 --------------------------
 
@@ -344,6 +349,8 @@ Here's the code for the scheduling tutorial::
     # ('class', class_name) = seats_left
 
     db = fdb.open()
+    db.options.set_transaction_timeout(60000)  # 60,000 ms = 1 minute
+    db.options.set_retry_limit(100)
     scheduling = fdb.directory.create_or_open(db, ('scheduling',))
     course = scheduling['class']
     attends = scheduling['attends']