Frequently Asked Questions

If you're evaluating running ACID transactions in an In-Memory Data Grid (IMDG), you probably have a few questions about scalability, performance, and coding. Take a look at these FAQs for using CloudTran. If your question isn't below, let us know so we can get you an answer and add it to our list!

Q  What about Java Persistence Queries - is it possible to use the same queries to lookup objects in the Grid as in a conventional JPA-layer?

CloudTran integrates with TopLink Grid, which is an adaptation of TopLink/EclipseLink for Coherence. EclipseLink itself is the reference implementation for JPA2. TopLink Grid provides different ways of integrating with the cache; in some of these, there are restrictions on the Java Persistence Queries you can use. See this link for more information.

Q  You have told us that 2 phase commit is not a good solution for doing transactions in coherence. What kind of algorithm do you use?

The requirements are: performance, persistence (data outside the grid is crucial), failover handling (data in the grid is crucial), scalability, no unbounded delays for clients.

In J2EE or J2EE lite, you had two backend tiers: the app servers (running servlets or sessions) and the database. Survival of the database was crucial - backups needed etc.

In a grid environment, you have three tiers - with cache machines in between the app servers and the database. Now it's not just the database that has to survive: the data in the grid is also critical. It also introduces a need to keep the cache and data tiers consistent.

Here are the basics of the CloudTran algorithm:

1. In a grid, you can configure any number of machines to act as transaction managers; could be a few nodes, or every node in the grid. As the grid scales up or scales down, so the transaction managers come and go but the transactions are guaranteed to commit as long as the grid isn't compromised.
2. At "begin transaction", our API in the app server acquires a transaction ID, and this is used to route to the appropriate transaction manager.
3. The application changes a particular Object - e.g. Customer#15. This change is reflected in the grid with a transactional entry, which also has the new value and the transaction. If another transaction tries to read this entry, it will get back the old (committed) value. If another transaction tries to change this entry with another transaction, it will get an optimistic locking exception.
4. If the transactional entry is correctly written, a copy is sent to the manager for this transaction.
5. When the client commits or rolls back the transaction, this is directed to the transaction manager which
   • gets a correct order for the transaction (to ensure isolation)
   • commits the transaction into the grid AND backs up to a local transaction log
   • returns to the caller - the transaction is free to go, before we start hitting the databases
   • then persists to the databases, using a "native" transaction to each database rather than a distributed transaction to get adequate performance.

This algorithm looks quite different compared to the Prepare/Commit of XA distributed transactions, but the write of the transactional entry into the grid serves the same purpose as the Prepare of XA.

Q  Do you know if there are cloud providers that deliver these solutions as a service?

We don't know of any, but it's an obvious evolution.

Q  CloudTran showed a demonstration with 10,000+ transactions per second. Were those distributed transactions?

Yes. They're not “XA distributed transactions“, but they are definitely distributed transactions! Small transactions may only involve 5 or 10 nodes, but there is no limit. In building CloudTran, we had in mind "big transactions", like an app we built for a customer: it committed 20-30,000 rows in one transaction.

Q  Do any applications need 10,000 transactions per second?

There are some today, but not many. However, proving this level of performance is important for two reasons. First, the outlook is for growth in size and performance of applications, so this shows that CloudTran can handle big increases without re-architecting. Second, it shows CloudTran can handle spikes, where instantaneous transaction rates (PER COMMIT) can go up 100s of times the average rate.

Q  Do you need RAC with a solution like Coherence?

The short answer is No, it is not a requirement. However, if your application requires lights-out persistence and linking to other applications, you will need some sort of data feed out of Coherence. The most common feed is to a database, and RAC is suitable because it is highly scalable. The choice of database is up to you.

Q  How much memory do individual machines have to have and how are the individual JVM tuned?

We typically run with 4GB, although it now makes sense to use more because of the off-heap and elastic data capabilities. For JVM tuning, the most important thing is garbage collection. We use ConcurrentMark Sweep, incrementally. Through experimentation, we found that NewSize/MaxNewSize=80M and MaxTenuringThreshold=1 keeps GCs at around the 20ms mark.

Q  What are the best settings (in operational sense) to tune the cache? For example, what fine tuning can one make in terms of communication when one detects slow nodes in the network?

We don’t know of anything you can do at run-time to detect and tune “slow nodes”. We do run the Coherence datagram tester, and if one node is constantly reporting high error rates, we don’t use it. But at run time, you have to live with it. The dreaded “communication delays” message is quite common, particularly if you’re on a busy public cloud with other users hammering the network. We let Coherence handle this level of detail - and eventually remove a node from the cluster if it’s too slow.

Q  How does Coherence differ from, or integrate with RAC?

RAC is a clustered database; Coherence is an in-memory data grid. I don’t know of any specific integration. You have the same integration as you would with any database.