What kinds of problems would there be when sharing TN DB between servers? In Stephen’s scenario, we can simplify the problem to having two IS sharing TN DB concurrently – I’m thinking of the cluster as a single IS, with a major difference that the clustered systems will be connected via Broker, the lone system may or may not.
When a doc is submitted to TN (at least for RosettaNet), the doc is published after recognition and persistence. What then?
It seems to me that if both sides are connected via Broker, Models could be kicked off on both sides. And in a multi-doc transaction (like RN PIP 3A4 PO Request), you could get multiple response docs to the same incoming request.
Or, as Rob pointed out, task scheduling would be a mess, if the two sides are meant to share pretty much the same work.
What happens when you have both sides doing polling notifications (i.e. JDBC adapter). My head aches just thinking about this… 8|
If both sides are not meant to be joined that tightly, I could still see some trouble in daily operations though. Docs received/processed on the other side would just pop up magically in Transaction analysis, but its processing status (WmMonitor) would only be available on one side. Definitely freaky…
What all this boils down to is that I don’t know Stephen’s rationale for having such a configuration. It might be okay for certain usage, but my point is that it’s not suitable for general usage. Almost like having clustered servers w/o clustering being set up…