Oracle Coherence is an in memory Data Grid framework, data replication and distributed services.In fact Coherence is a sort of Â data store. To test or debug data access code can be quite complicated. You need to set up test data, perform the test, and then clean up after each test, in order to ensure that itÂ does not influence the outcome of another test.
There are no real tools for Coherence to use, but in fact they are not necessary .
Setting up test data can be as simple as creating a bunch of Â files and using the Coherence CacheLoader to import them into the coherence cache.
Clearing data from the cache between the tests is even simplerâ€”just call the clear command from the Coherence commandline ( to be started with coherence.sh or coherence.cmd).
Coherence is not only a data store, but a distributed processing engine aswel. When you execute a query or anÂ aggregator ( like in Oracle Service Bus), it executes across all the nodes in the cluster. When you execute an entryÂ processor, it might execute on all nodes in parallel,Â depending on how it was invoked.
For the most part, you can test the code that executes within the cluster the sameÂ way you test more conventional data access code, by having each test case start a
one-node cluster. This makes debugging quite simple, as it ensures that all the code,Â from test, to Coherence, to your custom processing code executing within Coherence
runs in the same process.
You should be aware that this way of testing won’t be in a repesentable environment. All kinds of things changeÂ internally when you move from a one-node cluster to two-node cluster. For example,Â Coherence will not create backups in a single-node setup, but it will as soon as theÂ 2nd node is added to the cluster.
In some cases you might have to test and debug your code in a true distributedÂ environment, because it depends on things that are only true if you are in clustered mode.
Debugging in a distributed environment can be quite trivial. You willÂ need to enable remote debugging on a cache server node by adding the followingÂ JVM arguments to DefaultCacheServer run configuration( to be set in the coherence-cache-config.xml):
Also you need to ensure that all the data is stored on a cache server nodeÂ where remote debugging is enabled. That will ensure that the code you need
to debug within the cluster, such as the entry processor mentioned earlier, isÂ guaranteed to execute on that node.
Even though you will only be able to start one DefaultCacheServer now ( the remote debug port it is set to it), as soon as your test invokes any
CacheFactory method it will join the cluster as a second node. By default, the dataÂ is balanced automatically across all the nodes in the cluster, which will make it
impossible to ensure that your processor executes where you want.
If you’d like to disable one node of storing cache data, you simplyÂ I add the following JVM argument to yourÂ configuration( also again in the coherence-cache-config.xml):
In this picture you can see 2 JVM are not writing cache locally ,so it’s easier to test and debug because you configured them to false