The Beta 3 release focuses on major improvements across our language APIs, including new capabilities for locality, watches, transaction cancellation and timeouts, explicit conflict ranges, and atomic operations. It also improves performance and removes known limitations.
Discover where keys are physically stored using the new locality API.
Create watches that asynchronously report changes to the values of specified keys.
Explicitly add read or write conflict ranges.
Perform atomic operations that transform a value (e.g. incrementing it) without client reads to avoid transaction conflicts.
API version updated to 23.
Based on customer feedback and internal testing, the API has been significantly revised for increased performance and ease of use. This is a breaking API change. We will continue to make the previous JAR available for the time being.
The asynchronous programming library has been moved to its own package (
com.foundationdb.async). The library has a host of new members for greater flexibility and more predictable error handling.
Database.run(...)can now return an arbitrary object from user code, simplifying use of this recommended retry loop.
The new interface
Functionreplaces several interfaces:
Added the ability to cancel any
Futureinstance, even one not backed with native resources.
onFailure()in favor of
flatMap(). If code needs simple triggering,
onReady()is still available.
Range iteration via
Transaction.getRange(...)starts fetching data immediately upon invocation. This simplifies development of code that reads ranges in parallel.
Many other changes that facilitate writing fast, efficient, and correct Java applications!
Python API methods that accept a key will also accept a Python object with an
as_foundationdb_key()method that returns a key. Likewise, methods that accept a value will also accept a Python object with an
as_foundationdb_value()method that returns a value.
Clients can preferentially communicate with servers on the same machine or in the same datacenter for location-aware load balancing.
Removed from the client library debugging code included in versions up through Beta 2, leading to higher, more predictable performance.
Improved data distribution algorithms to optimize data movement during failure scenarios.
Improved range-read iterators in Node.js using lazy evaluation.
Improved client-side range-read prefetching in Node.js, Ruby, and Python.
Incrementally improved performance across all language bindings.
A storage node could be prevented from rejoining the cluster until the process was restarted.
GetRangerequest using a row limit and an end key selector that enters the system keyspace could return too few results.
A machine power loss immediately following a process restart could result in an invalid transaction log.
GetRangecould improperly cache too large a range of data when the end key selector resolved past the end of user keyspace, temporarily resulting in incorrect answers to read requests.
In Node.js, reusing a range iterator for a second request could result in an incomplete result set.