0

Background]
- There are two java applications (A and B), and they can only communicate via Oracle DB
- A and B share the same database table
- A and B stores the data in cache

Problem]
If A performs simple transaction (insert/update/delete), the cache in A is updated. Also, the cache in B should be updated automatically!

Current Status]
Two solutions I found and tried
- Solution1) Using DatabaseChangeListener
- Solution2) Using Socket Programming

Question]
The solution will be used for company, and I would like to know if there is anything that I can improve my solutions.
1) What could be disadvantages if I use DatabaseChangeListener?
2) What could be disadvantages if I use socket programming? (Maybe it's too low-level that developer cannot maintain due to company policy?)
3) I heard there are 3rd party cache that also supports synchronization. Am I correct?

Please let me know if you need more information!

Thank you very much in advance!

[EDIT]
If would be much appreciated if you can leave a comment when you down-vote this. I would like to know how I can improve this question with your feedback! Thank you

Adrian
  • 836
  • 7
  • 20
  • 44

2 Answers2

2

Your question appears every now and then with slightly different aspects. One useful answer to that is here: Guava Cache, how to block access while doing removal

About using the DatabaseChangeListener:

Although you are fine with oracle, I would discourage the use of vendor specific interfaces. For me, it would be okay to use, if it is an performance optimization, but I would never use vendor specific interfaces for basic functionality.

Second, the usage of the change listener may still lead to dirty reads.

About "distributed caches" as veritas suggested:

There is a difference between distributed caches and clustered caches. Distributed caches spread (aka distribute) the cached data on different nodes, clustered caches are caches for clustered applications that keep track of data consistency within the cluster. A distributed cache usually is a clustered cache, but not the other way around. For a general idea on the topic I recommend the infinispan documentation on clustering as an intro: http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_clustering

Wrap up:

A clustered cache implementation is the thing you need. However, if you want data consistency, you still need to carefully design your transaction handling.

You can, of course, also do socket communication yourself and send simple object invalidate messages to the other applications. The challenging part is the error handling. When was the invalidate successful? Is there a timeout for the other nodes to acknowledge? When to drop a node and maintain a cluster state at all?

Community
  • 1
  • 1
cruftex
  • 5,545
  • 2
  • 20
  • 36
  • Thank you very much for the response :). I understand that the use of vendor specific interfaces (DatabaseChangeListener) should be avoided. Would you be able to provide more detailed reason? I only can see that 'dirty reads'. Can I rephrase it like 'hard to understand if user does not have knowledge about DatabaseChangeListener'? – Adrian Jan 07 '15 at 00:43
  • 1
    I not sure that I don't get you question completely. Vendor specific interfaces should be avoided because of a possible vendor lock in. And yes, of course, a developer needs always more knowledge the more interfaces you use. – cruftex Jan 07 '15 at 02:05
-1

I will suggest for the 3rd Party Cache, if you have many similar use cases or many tables need to be updated .

Please read about terracotta Distributed Cache. It gives exactly what you want.

You can also look for hazelcast or memcached

veritas
  • 2,444
  • 1
  • 21
  • 30