About the Java driver
Use this driver in production applications to pass CQL statements from the client to a cluster and retrieve, manipulate, or remove data.
The Java driver is a modern, feature-rich and highly tunable Java client library for Apache Cassandra (1.2+) and DataStax Enterprise (3.1+) using exclusively Cassandra's binary protocol and Cassandra Query Language v3.
Use this driver in production applications to pass CQL statements from the client to a cluster and retrieve, manipulate, or remove data. Cassandra Query Language (CQL) is the primary language for communicating with the Cassandra database. Documentation for CQL is available in CQL for Cassandra 2.x. DataStax also provides DataStax DevCenter, which is a free graphical tool for creating and running CQL statements against Apache Cassandra and DataStax Enterprise. Other administrative tasks can be accomplished using OpsCenter.
What's new in 2.0.10?
- Revert of JAVA-425, which marked a node down when a query timed out, and led to NoHostAvailableExceptions under high load (probably our most requested change!) This no longer happens, and if a node is really having problems, it will be detected by other existing mechanisms (notification from another node that detected it through gossip, failed connection heartbeat).
- Upgrade of Netty to 4.0.27 and application-side coalescing of protocol frames.
- Speculative executions to preemptively retry requests when a host takes too long to reply (the client-side equivalent to Cassandra's rapid read retry).
- Query logger that allows you to trace slow or failed queries.
- Access to the paging state and ability to re-inject it into a statement.
- New pool resizing algorithm (JAVA-419) that fixes issues with variable-sized pools (core connections != max).
- Internal optimizations around connection usage.
- EC2 address translator (Previously released in version 2.1.5), connection heartbeat, and token metadata API.
- Cassandra 2.0 support
- Lightweight transactions
Lightweight transactions have been added to Cassandra 2.0 to enable compare-and-set operations. Since these operations require a distributed consensus, you should not expect performance to be as good 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.
- Parameterized statements
Sometimes, even though, you need to send a query just once it uses UUIDs or blobs which are inconvenient to serialize in the CQL string. With the 1.0 version of the driver, you might have used a prepared statement for these binary parameters to solve the problem. Cassandra 2.0 introduced parameterized statements which allow you to provide parameters to regular statements, still using the question mark as a placeholder.
- Automatic result set pagination
Allows you to iterate indefinitely over the ResultSet, having the rows fetched block by block until the rows available on the client side are exhausted. This makes it easier to manipulate large result sets while also shielding the client application from instantiating an accidentally large ResultSet object.
- LZ4 support
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, both for compression and decompression.
- Lightweight transactions
- Latency-aware policies
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 built-in policies provided by the Driver. In version 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. Since this policy acts as a filter, it can be combined with a data-center aware balancing or any other existing policy.
- Fewer dependencies
Version 1.0 of the driver relied on several dependencies such as cassandra-all, which in turn had many dependencies of their own. If you’re upgrading from the Java Driver 1.0, you'll notice that the dependencies of the Java Driver 2.0 have been reduced to four.
- Improved testability
This new version of the driver simplifies testability by exposing many components of the driver as interfaces (instead of classes) thus making it possible to mock commonly used interfaces such as Session, ResultSet, Row, or PreparedStatement.