Update query timestamps doc now that client-side is the default.

olim7t · olim7t · commit 2edebf9124e5 · 2015-06-03T15:29:17.000+02:00
diff --git a/features/query_timestamps/README.md b/features/query_timestamps/README.md
@@ -5,16 +5,6 @@ is used to order operations relative to each other.
 
 There are various ways to assign it:
 
-### Server-side generation
-
-If the client does not specify any timestamp, the server will assign one
-based on the time it receives the query.
-
-This can be a problem when the order of the writes matter: with unlucky
-timing (different coordinators, network latency, etc.), two successive
-requests from the same client might be processed in a different order
-server-side, and end up with out-of-order timestamps.
-
 ### CQL `USING TIMESTAMP`
 
 You can explicitly provide the timestamp in your CQL query:
@@ -24,29 +14,24 @@ session.execute("INSERT INTO my_table(c1, c2) values (1, 1) " +
     "USING TIMESTAMP 1432815430948040");
 ```
 
-This solves the problems of server-side generation: the client has
-control over the ordering of the statements it generates. On the other
-hand, it puts the burden of generating timestamps on client code.
-
 ### Client-side generation
 
-Starting with version 2.1.2 of the driver, and if [native
-protocol](../native_protocol/) v3 or above is in use, a *default
-timestamp* can be sent with each query.
+This is enabled by default if you're using the driver 2.2 and a version
+of Cassandra that supports [native protocol](../native_protocol) v3 or
+above.
 
-To enable this feature, provide an instance of [TimestampGenerator][tsg]
-at initialization:
+A client timestamp will be sent by each query. It is generated by a
+[TimestampGenerator][tsg]. The default implementation is
+[AtomicMonotonicTimestampGenerator][amtsg].
+
+You can specify another generator at initialization:
 
 ```java
 Cluster.builder().addContactPoint("127.0.0.1")
-    .withTimestampGenerator(new AtomicMonotonicTimestampGenerator())
+    .withTimestampGenerator(new MyCustomTimestampGenerator())
     .build();
 ```
 
-The default is still server-side generation. So unless you explicitly
-provide a generator, you get the same behavior as previous driver
-versions.
-
 In addition, you can also override the default timestamp on a
 per-statement basis:
 
@@ -58,6 +43,22 @@ session.execute(statement);
 ```
 
 [tsg]: http://docs.datastax.com/en/drivers/java/2.2/com/datastax/driver/core/TimestampGenerator.html
+[amtsg]: http://docs.datastax.com/en/drivers/java/2.2/com/datastax/driver/core/AtomicMonotonicTimestampGenerator.html
+
+
+### Server-side generation
+
+This is the "legacy" behavior if you're connected to a Cassandra version
+that only supports protocol v2 or below. The server will assign a
+timestamp based on the time it receives the query.
+
+This can be a problem when the order of the writes matter: with unlucky
+timing (different coordinators, network latency, etc.), two successive
+requests from the same client might be processed in a different order
+server-side, and end up with out-of-order timestamps. If protocol v3 is
+not an option, the only workaround is to add `USING TIMESTAMP` in your
+queries.
+
 
 ### Summary
 
diff --git a/features/speculative_execution/README.md b/features/speculative_execution/README.md
@@ -332,11 +332,7 @@ But now the second execution of the first query finally reaches its
 target node, which applies the mutation. The row that you've just
 deleted is back!
 
-The workaround is to use a timestamp with your queries:
-
-    insert into my_table (k, v) values (1, 1) USING TIMESTAMP 1432764000;
-
-If you're using native protocol v3, you can also enable client-side
-timestamps to have this done automatically; see
-[this blog post](http://www.datastax.com/dev/blog/java-driver-2-1-2-native-protocol-v3)
-for more information.
+The workaround is to use
+[client-sidetimestamps](../query_timestamps/#client-side-generation) (if
+you're using native protocol v3 or more, the driver already does this
+automatically.
