Re: Constant Update of SQl Server from an iSeries

On Wed, Nov 19, 2014 at 12:52 PM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

You have to write them somewhere in case you can't reach the SQL server.

... it depends on your requirements, if both databases have to be in sync,
then you must not write to as400, if the SQL Server is not reachable.

​Sure, good theory...till the first time the SQL server is down and your i
won't allow any work either​! ;)

I've yet to see where management's requirement for DB's to be "sync'd"
meant they were willing to accept such downtime.

Direct communication from a trigger strikes me as a bad idea in general.

Consider there's no way to handle a set of changes being rolled back; as
the trigger doesn't get called again. Unless ARDGATE supports distributed
transactions (XA)?

Rollback would not be a big problem. ArdGate doesn't support distributed
unit of work, but it will notice commit operations and propagates
commit/rollback to all database connects in the same ACTGRP. (There remains
a small gap, if the connection breaks within a transaction).

D*B

​How does that work? As understand ArdGate, the JDBC connection to SQL
server is handled by the AppServer running in another job.

So if the trigger does a connect / update..

How is it possible for ​

​ArdGate to know when DB2 does the commit and to propagate that commit?​