On Wed, 2005-12-28 at 15:59 -0600, Shull, David (VA Team) wrote: > > > On a Intersystems Cache based configuration, one might consider a > DB/Application server type configuration to address this problem.
[KSB] <...snip...> > I am not sure if GT.M has the ability to do a similar type > configuration, it’s been a long time since I worked with it and I am > just not up to speed on all the features. [KSB] While GT.M does have the ability to set up a client/server configuration of a database, I don't think a real-time client/server based approach is the right one for Kevin. Nor do I think a 2-phase commit is the right approach. What happens if the network fails? I presume it would not be acceptable for the local side to not be able to commit updates locally if the remote side is inaccessible because of a network failure? I think not. Below are some other options. 1. An overnight batch process that extracts the preceding day's updates from the database and creates an export file that is shipped to the other side and imported. This will require a little programming, but hopefully it will be minimal. 2. For each site, create a secondary on the other site using GT.M database replication. In that secondary, all of a patient's data from a remote site are available on a read only basis in near real time. GT.M database replication is very robust, and the primary is unaffected if the network goes down, and when it comes back up, the secondary catches up automatically and transparently. This can be implemented today with no programming. 3. Use an MPI style approach (probably the most elegant, especially for the day when Kevin's patients have web access to their medical records, but one requiring the most programming). -- Bhaskar ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
