-
15. Re: <xa-datasource>
correct - this is why I was careful to explicitly state my assumptions. It sounds as though he's storing statistic/monitoring data (??) after the critical commit is complete. And I assume this stats/monitoring data is therefore not critical nor does it need to be synced later. i.e. the data stored in db2 is volatile and it is not detrimental if it fails to be committed - i.e. losing it is acceptable
-
16. Re: <xa-datasource>
Jonathan Halliday wrote:
That's a seductively simple solution, but actually only correct if the business requirements allow for it.
+1
I assumed from the description related to temperature readings and a reference to "minute" then I figured that whatever business logic reads from DB2 is happy with stale date until an updated reading comes in.
The thing I think would make this cool is some JMS. Rather than DB2, send a message to a topic and then the things that were reading from DB2 would now consume from the topic. Basically, if this data is as none-critical as it is being made out to be, I am not sure I would bother putting it in a DB. But then, I don't suppose we have enough info be certain that the data is as none-critical as it sounds.
-
17. Re: <xa-datasource>
As i said, temperature is an example. My app is lot more complex.
But with the same behaviour.
JMS is not the best approach in this case, but is a valid solution!
I'm not going into details of the application, but let's assume I want to do the update of the two databases at the same time without worrying that the failure of db2 commit affects db1, and this is the best approach.
Is there a better / faster way to do this?