CloudTran is a product family for Java developers who need to build high-performance, scalable applications with strong ACID guarantees.
CloudTran provides a scalable data tier in support of in-memory data grids.
CloudTran-Coherence for TopLink Grid helps Java application programmers write scalable JPA applications using
and TopLink Grid.
There is a growing requirement for applications to respond more quickly, process more transactions per second, handle larger datasets and do more computation per transaction.
These requirements are driven by the growth in mobile applications, globalisation, growth in micropayment volumes
and the constant demand for more data and more business intelligence by consumers and regulators.
3.1.1 Less time, higher throughput, more data and more business logic|
The standard architecture for web applications, with scalable web and processing tiers backed by one database(s) cannot handle these requirements past a certain point.
The first fundamental problem is the load on the database during read and searching operations; this can be alleviated by caching, up to a point.
But eventually, these requirements make the database-oriented architecture unviable simply because of the update/write processing.
To meet the performance requirements, the live data must be nearer to the user. This requires a new architectural approach.
One approach is to use a NoSQL solution - where relational databases are not used at all for storing information, transactional integrity is not guaranteed
and the programming paradigm is quite different.
However, NoSQL's lack of transactional integrity and the way it severs links to business intelligence applications
makes it unattractive for business-critical commercial applications.
The new part of the architecture is the in-memory data grids - a number of nodes that cooperate to provide a unified cache layer,
holding business data that can be instantly processed.
In other words, the data grid's primary purpose is to provide data as a shared resource to service operations in the service tier.
3.1.2 The Data Grid|
CloudTran supports an architectural style where all the data involved in a transaction is resident in the grid - so the grid is the system of record.
This does not mean that all the data in an application needs to be in the grid.
Non-transactional data, like catalog data, can be in other data stores.
The reason for using this style of architecture is that it is scalable.
It prevents the database from becoming a bottleneck.
Although it is possible to "scale" databases by sharding, this tends to create problems with transactionality and manageability.
Unfortunately, there are two centers of control for transactions in grids - the database; and the grid.
Databases are well known for their attention to transactionality.
Grid products typically provide transactionality too, but it is in-memory only.
3.1.3 The Persistence Dilemma|
The persistence dilemma is that either
- transactions commit to the database first ("write-through"), which tends to slow the grid down and is expensive to scale
- transactions commit to the grid first and then lazily committing from various grid nodes to the database ("write-behind").
This is relatively fast to commit, but then loses the ACID properties of the transaction because the data is persisted from different nodes at different times.
A common development strategy is to code around these problems.
This makes development more complicated and maintenance more risky, and has a way of getting out of hand as the application grows more complex.
CloudTran provides a new style of transaction to address these problems.
The key is that CloudTran manages information in the grid and en route to the database as a single unit, from within the grid. It provides
3.1.4 CloudTran Transactions|
- high-speed ACID commits to the grid, which return to the caller before hitting the database
- transactional persistence to databases (i.e. the data is collected from the cache nodes) on a native connection
- multi-transaction aggregation to boost database write performance
- scalability - the transaction manager itself is scalable and can scale with the data grid
- smooth over spikes - the grid can handle load and buffer transactions at peak times
- non-stop protection - carry on if the database is unavailable
- simple to develop - standard TopLink Grid and JPA.
- lights-out protection using transaction logging in the grid
- impervious to distance to the database in Grid Entity mode
Here's a diagram of the CloudTran architecture:
3.1.5 How CloudTran Works|
The Client Application is a standard JPA application for the TopLink Grid platform.
You do not need to change the domain model or business logic when introducing CloudTran.
A couple of changes are required to inject the hooks for CloudTran transaction,
which can be made in the code using annotations or in the XML configuration.
Cache Nodes and Transaction Managers preferably run in the same cache nodes -
so each JVM running the Coherence data caches will also have a CloudTran Transaction Manager ('Manager').
In very large grids with many nodes required for the data cache,
the grid may be easier to manage with the data and manager caches configured onto different nodes: this is also possible with CloudTran.
The transaction manager handles
More details of the transaction manager operation are given later.
- the transaction lifecycle requests (i.e. start, commit, rollback)
- collecting copies of the changed information
- ensuring the database writes do not get out of order, with a little help from the isolator
- instructing the cache nodes to commit their transactions on commit, to make the "in process" values become "committed"
- saving temporary copies of the data in the local transaction log. This is used, if the grid fails completely, to finish any
to the database before restarting the grid
- persisting to the various databases.
To give an order of magnitude idea of the power of a transaction manager,
a combined data and cache node with a commodity 4-core single-socket processor and 1Gbps networking
handles roughly 300-400 transactions (7 read items and 3 updates in a transaction) per second in large configurations,
and more than that in small configurations.
This is indeed an order of magnitude, for 'cruising speed' and long-term operation.
Deployment structure, threading, network performance and database performance (driver, raw throughput) and spikes in load
can increase or reduce that number significantly.
The Isolator is the point where the correct order to the database is established.
The issue here is that, even though the transactions are isolated at the managers and order is correct at commit time,
a manager may be delayed persisting a transaction to the database.
If a later transaction overtakes an earlier one, it is possible to send updates to the database in the wrong order.
Whereas the transaction manager scales out, the isolator is deployed as a primary and one or more secondaries, because the ordering must be focussed at one point.
The isolator is not a bottleneck for practical deployments today because the ordering algorithm handles 100,000's of rows per second per core on commodity servers.
In future, scalability of the isolator is possible by sharding the database (if necessary) and having one isolator per database.
DataBases (or 'datastores'). CloudTran provides management of updates to
databases out of the box. Updates to other datastores, such as NoSQL, or double updates, such as feeds to parallel grids,
can be added in code at integration points in CloudTran.
The type of applications that are likely to need the large dataset, intense processing or high transaction rates provided by CloudTran are:
- Web Sites To Scale. Web sites that are reaching the limit that their current database-oriented architecture
Development teams that need to make many tactical performance improvements can
move to an architecture that can scale easily, freeing up resources for more customer-centric improvements
- Remote Databases . CloudTran can use remote databases for persistence
without reducing application performance, because the databases' time to reply is not a factor in application performance
(it is the grid's time to reply that matters).
This makes it possible to deploy applications in the cloud with the grid holding live application data
and persisting to databases in the data center.
This reduces security risks and concerns around storing data in public clouds.
- Application Integration.
In practice, standard applications today are built around databases.
This makes integration across applications slower to develop and slower at runtime.
Using grids as the integration point makes applications easier to develop and much faster at runtime.