Need advise on Write-Behing For Financial Systems

Question

Hi,
I am trying to understand how Coherence transactional write behind works for trading systems. I am particularly interested in the transactional guarantees of write behind transactions on a trading platform. I understand that Coherence has been used to implement such systems.
Please shed more light on the following
1. What are things to keep in mind while using write behind for online financial trading systems
2. How does Coherence compare against times ten to increase the performance of such syhstems? Is times ten better suited than Coherence for such scenarios?
3.How does Coherence handle a total system crash when the transactions are still in flight (and pending in write behind queues)?
4. What kind of safety measures should we take architecturally to safeguard against data losses?
Any advise would be very helpful
Thanks
Sairam

Answer 1

1. What are things to keep in mind while using write behind for online financial trading systems
Probably the most important thing to keep in mind is the need for ensuring that write behind pushes
stuff to the database in an idempotent manner.
2. How does Coherence compare against times ten to increase the performance of such systems? Is times ten better suited than Coherence for such scenarios?
Times Ten has gateways to push memory resident rows down into a database, as does Coherence. A big difference
between the two technologies is that Times Ten is relational whereas Coherence is object based with key value retrieval.
Both are excellent technologies but model data differently. In Coherence you use Map interfaces to manage data, in Times Ten
you use SQL.
3. How does Coherence handle a total system crash when the transactions are still in flight (and pending in write behind queues)?
Typically write-behind is done by putting write operations in memory queues. The default is to have a backup queue typically
located by the cache server that manages the backup of the entry. Out of the box Coherence will backup updates and backup
queues to another server. This is configurable and you can have more than one backup service.
If the primary service goes down, the backup takes over the responsibility of writing to the database.
4. What kind of safety measures should we take architecturally to safeguard against data losses?
Tuning the number of backups is important. If you are really concerned about the loss of an entire site (i.e. cluster)
you might want to look at PushReplication solutions provided by Coherence Incubator.