DataStax Java Driver 2.0 now available!
We are happy to release today, at the same time with DataStax Enterprise 4.0 and OpsCenter 4.1, the final version of our Java Driver 2.0 for Cassandra. The focus of this release was complete compatibility and support for Cassandra 2.0, but we’ve used this opportunity to incorporate the feedback we’ve received, add several new features and improvements, and also get rid of some cruft. Unfortunately this means that we’ve had to make some breaking chances (fully documented here), but we hope that transitioning to the new API will show its benefits right away. Last but not least, the driver remains compatible with Cassandra 1.2 which means you can plan for a smooth transition to Cassandra 2.0 as you switch to this improved API.
Now, let’s have a tour of the new and noteworthy features of this new driver.
Cassandra 2.0 support
Lightweight transactions have been added to Cassandra 2.0 to enable Compare-and-set operations. As they require a distributed consensus, you should not expect performance as great as for regular reads and writes but they make it possible to handle some extra use cases in Cassandra such as stock management for e-commerce websites or unique username allocation.
Batching prepared statements
While in Cassandra 1.2 it was possible to create a PreparedStatement from a BATCH query, Cassandra 2.0 also makes it possible to batch prepared statements, making it much easier for developers to send multiple INSERTs or UPDATEs to Cassandra without the overhead of multiple network round-trips.
Sometime you need to send a query only once but it comes with some UUIDs or blobs that are not convenient to serialize in the CQL string. Up to now it was tempting to use a prepared statement to enjoy their binary parameters and solve the problem. Cassandra 2.0 introduce parameterized statements which allows you to provide parameters to regular statements, still using the question mark as a placeholder.
Automatic result set pagination
Automatic result set pagination allows to iterate indefinitely over the ResultSet, having the rows fetched block by block as the ones available on the client side get exhausted. It makes it much easier to manipulate large results while also shielding the client application against accidentally large ResultSet.
Support for LZ4 comes as an additional compression option in Cassandra 2.0 besides Snappy. LZ4 is known to have a compression ratio roughly equivalent to Snappy while being much faster, for both compression and decompression. The new version of the driver supports now LZ4.
Latency aware policy
Load balancing in the DataStax Drivers is handled by a flexible Policy architecture where the user is free to define his own custom strategy beyond the builtin policies provided by the Driver. In the Java Driver 2.0 we introduce a LatencyAwarePolicy which tracks the response times of each Cassandra node and routes the requests to the nodes that are currently the fastest to answer. As this policy acts as a filter, it can be combined with a data-center aware balancing or any other existing policy.
So far, the Java Driver was relying on several dependencies such as
cassandra-all, which comes itself with many dependencies. This has helped us to write the initial version of the Java Driver faster by reusing several transport parts from Cassandra, but they’re not necessary anymore.
If you’re upgrading from the Java Driver 1.0, you’ll be glad to observe that the only dependencies of the Java Driver 2.0 are now
slf4j. These are expected to remain on the long term.
This new version of the driver should simplify testability by exposing many components of the driver as interfaces (instead of classes) thus making it possible to mock commonly used interfaces such as
The new version of the driver is already available from the Maven repositories. As a new option, you can also download it as a packaged binary. And if you are upgrading from the 1.0 version of the driver, we have published an Upgrade guide. Thank you for using and supporting Apache Cassandra and DataStax.