ER question
Frank asked whether Enterprise Replication (update-anywhere, IDS 10 UC5 on AIX 5.3) can retry a replicated update a few seconds later when the target row hasn't arrived yet from a third site, instead of aborting the transaction. An IBM ER engineer said there is no retry logic (except lock waits via CDR_DSLOCKWAIT) and suggested timestamp conflict resolution so the update is converted to an insert and the later-arriving row is rejected; Frank objected that his sites' clocks can't be kept in sync, so no fully satisfactory fix emerged. A side question from Laurie was answered: cdr check -R deletes extra target rows unless you add --extratargetrows=merge, which worked for her.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
HI, Folks, A question about ER update anywhere implementation. If a row update ( from site C) can not be completed on site B ( because the corresponding row does not exist at that time, it was originated at site A and has not arrived at B yet), can we allow the update at B to have another try (e.g., in 5-10 seconds later) instead of just simply abort it? IDS10 UC5, AIX 5.3 Thanks, Frank
Not sure if someone has replied to your question. You probably has defined conflict rule=3Dignore in your replication. In= an update anywhere replication, the update row will be discarded if the ro= w does not exist on target (site B). That is for ignore conflict rule resolution. You can manually insert the row in site B. It will be disca= rded by site A and site C as ignore conflict rule kick in. Please find below for the appropriate conflict rule you want for your replication. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= /com.ibm.erep.doc/erep75.htm ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ = "FRANK" = <yunyaoqu@gmail.c = om> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect ER question [10706] = 12/11/2007 02:48 = PM = = = Please respond to = ids@iiug.org = = = HI, Folks, A question about ER update anywhere implementation. If a row update ( from site C) can not be completed on site B ( because= the corresponding row does not exist at that time, it was originated at= site A and has not arrived at B yet), can we allow the update at B to have another try (e.g., in 5-10 seconds later) instead of just simply abort it? IDS10 UC5, AIX 5.3 Thanks, Frank ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
Wee, You are the first one replied. Madison must be on vacation. :-( When the row to be updated does not exist, The whole transaction will be aborted ( the update is only part of it ). Aborting whole transaction is fine with us because we do not want partial result in database. If ER gives the failing transaction another opportunity to try ( seconds later), it will be done! Because the row is on the way from site A to site B ( slower network from A to B, but from A to C to B is fast!). Hope I explained the problem. Thanks, Frank On Dec 12, 2007 3:49 PM, Wee Tung <wtung@us.ibm.com> wrote: > Not sure if someone has replied to your question. > You probably has defined conflict rule=3Dignore in your replication. In= > an > update anywhere replication, the update row will be discarded if the ro= > w > does not exist on target (site B). That is for ignore conflict rule > resolution. You can manually insert the row in site B. It will be disca= > rded > by site A and site C as ignore conflict rule kick in. > > Please find below for the appropriate conflict rule you want for your > replication. > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= > /com.ibm.erep.doc/erep75.htm > ______ > Software Engineer > IBM Information Management > Informix ER IDSQA > wtung@us.ibm.com > 913-599-7234 > __________________________________ > > = > > "FRANK" = > > <yunyaoqu@gmail.c = > > om> = > To > > Sent by: ids@iiug.org = > > ids-bounces@iiug. = > cc > > org = > > Subj= > ect > > ER question [10706] = > > 12/11/2007 02:48 = > > PM = > > = > > = > > Please respond to = > > ids@iiug.org = > > = > > = > > HI, Folks, > > A question about ER update anywhere implementation. > > If a row update ( from site C) can not be completed on site B ( because= > > the corresponding row does not exist at that time, it was originated at= > > site A and has not arrived at B yet), can we allow the update at B to > have another try (e.g., in 5-10 seconds later) instead of just simply > abort it? > > IDS10 UC5, AIX 5.3 > > Thanks, > Frank > > ***********************************************************************= > ******** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > = > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >
ok - but I have a question. If the replicate is set up with a conflict of timestamp.. and update anywhere, and it is a master=serverA.. then things go wrong and serverA and serverB are out of sync... some rows are inserted on serverB while replication is down when replcation comes back up.. and I do cdr check -R to resync the data in the tables... what happens (or should happen) to the rows inserted on ServerB? I just did this and it appeared that serverB had 3 extra rows, but rather than send them to sererA, the 3 rows were deleted Is this the way it is supposed to work? or am I just doing something wrong? Thanks Laurie Laurie Gustin IT Programmer Analyst Department of Public Safety lgustin@utah.gov 801-965-4410 >>> "Wee Tung" <wtung@us.ibm.com> 12/12/07 1:49 PM >>> Not sure if someone has replied to your question. You probably has defined conflict rule=3Dignore in your replication. In= an update anywhere replication, the update row will be discarded if the ro= w does not exist on target (site B). That is for ignore conflict rule resolution. You can manually insert the row in site B. It will be disca= rded by site A and site C as ignore conflict rule kick in. Please find below for the appropriate conflict rule you want for your replication. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= /com.ibm.erep.doc/erep75.htm ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ = "FRANK" = <yunyaoqu@gmail.c = om> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect ER question [10706] = 12/11/2007 02:48 = PM = = = Please respond to = ids@iiug.org = = = HI, Folks, A question about ER update anywhere implementation. If a row update ( from site C) can not be completed on site B ( because= the corresponding row does not exist at that time, it was originated at= site A and has not arrived at B yet), can we allow the update at B to have another try (e.g., in 5-10 seconds later) instead of just simply abort it? IDS10 UC5, AIX 5.3 Thanks, Frank ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. = ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Yes. I do understand your problem now. But, there is nothing ER can do = when slow network come in place. I don't think there is a retry logic in place when transaction got abor= ted unless the table is locked(by another transaction) and CDR_DSLOCKWAIT i= s set. I'm not sure what is your priority in each ER site setup, but what you = can do for problem like this is to setup ER with timestamp conflict resolut= ion. Even with slow network, site C update row will get insert into site B a= nd when site A insert row arrived at site B, it will get rejected because = of the timestamp. Hope this help. ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ = "FRANK" = <yunyaoqu@gmail.c = om> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect Re: ER question [10733] = 12/12/2007 03:33 = PM = = = Please respond to = ids@iiug.org = = = Wee, You are the first one replied. Madison must be on vacation. :-( When the row to be updated does not exist, The whole transaction will b= e aborted ( the update is only part of it ). Aborting whole transaction is fine with us because we do not want partial result in database. If ER gives the failing transaction another opportunity to try ( second= s later), it will be done! Because the row is on the way from site A to s= ite B ( slower network from A to B, but from A to C to B is fast!). Hope I explained the problem. Thanks, Frank On Dec 12, 2007 3:49 PM, Wee Tung <wtung@us.ibm.com> wrote: > Not sure if someone has replied to your question. > You probably has defined conflict rule=3D3Dignore in your replication= . In=3D > an > update anywhere replication, the update row will be discarded if the = ro=3D > w > does not exist on target (site B). That is for ignore conflict rule > resolution. You can manually insert the row in site B. It will be dis= ca=3D > rded > by site A and site C as ignore conflict rule kick in. > > Please find below for the appropriate conflict rule you want for your= > replication. > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= 3D=3D > /com.ibm.erep.doc/erep75.htm > ______ > Software Engineer > IBM Information Management > Informix ER IDSQA > wtung@us.ibm.com > 913-599-7234 > __________________________________ > > =3D > > "FRANK" =3D > > <yunyaoqu@gmail.c =3D > > om> =3D > To > > Sent by: ids@iiug.org =3D > > ids-bounces@iiug. =3D > cc > > org =3D > > Subj=3D > ect > > ER question [10706] =3D > > 12/11/2007 02:48 =3D > > PM =3D > > =3D > > =3D > > Please respond to =3D > > ids@iiug.org =3D > > =3D > > =3D > > HI, Folks, > > A question about ER update anywhere implementation. > > If a row update ( from site C) can not be completed on site B ( becau= se=3D > > the corresponding row does not exist at that time, it was originated = at=3D > > site A and has not arrived at B yet), can we allow the update at B to= > have another try (e.g., in 5-10 seconds later) instead of just simply= > abort it? > > IDS10 UC5, AIX 5.3 > > Thanks, > Frank > > *********************************************************************= **=3D > ******** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > =3D > > > > ***********************************************************************= ******** > Forum Note: Use "Reply" to post a response in the discussion forum. > > ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
The default action when you do cdr check -R is all data on master(serve= r A) will get sync to the slave (server B) and delete the extra rows on serv= er B. If you want the 3 extra rows from server B to send to server A, you nee= d to add --extratargetrows=3Dmerge in cdr check command. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= /com.ibm.erep.doc/erep227.htm ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ = "Laurie Gustin" = <lgustin@utah.gov = > = To ids@iiug.org, Wee = 12/12/2007 03:56 Tung/Lenexa/IBM@IBMUS = PM = cc = Subj= ect Re: ER question [10732] = = = = = = = ok - but I have a question. If the replicate is set up with a conflict of timestamp.. and update anywhere, and it is a master=3DserverA.. then things go wrong and serverA and serverB are out of sync... some rows are inserted on serverB while replication is down when replcation comes back up.. and I do cdr check -R to resync the da= ta in the tables... what happens (or should happen) to the rows inserted= on ServerB? I just did this and it appeared that serverB had 3 extra rows, but rath= er than send them to sererA, the 3 rows were deleted Is this the way it is supposed to work? or am I just doing something wrong? Thanks Laurie Laurie Gustin IT Programmer Analyst Department of Public Safety lgustin@utah.gov 801-965-4410 >>> "Wee Tung" <wtung@us.ibm.com> 12/12/07 1:49 PM >>> Not sure if someone has replied to your question. You probably has defined conflict rule=3D3Dignore in your replication. = In=3D an update anywhere replication, the update row will be discarded if the ro= =3D w does not exist on target (site B). That is for ignore conflict rule resolution. You can manually insert the row in site B. It will be disca= =3D rded by site A and site C as ignore conflict rule kick in. Please find below for the appropriate conflict rule you want for your replication. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= 3D=3D /com.ibm.erep.doc/erep75.htm ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ =3D "FRANK" =3D <yunyaoqu@gmail.c =3D om> =3D To Sent by: ids@iiug.org =3D ids-bounces@iiug. =3D cc org =3D Subj=3D ect ER question [10706] =3D 12/11/2007 02:48 =3D PM =3D =3D =3D Please respond to =3D ids@iiug.org =3D =3D =3D HI, Folks, A question about ER update anywhere implementation. If a row update ( from site C) can not be completed on site B ( because= =3D the corresponding row does not exist at that time, it was originated at= =3D site A and has not arrived at B yet), can we allow the update at B to have another try (e.g., in 5-10 seconds later) instead of just simply abort it? IDS10 UC5, AIX 5.3 Thanks, Frank ***********************************************************************= =3D ******** Forum Note: Use "Reply" to post a response in the discussion forum. =3D ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
Thanks! I think that works... It was confusing though, because the output of the cdr check -R shows that mismatched rows are processed but doesn't show anything having happened to the extra rows... another cdr check showed that the rows were inserted to serverA Thanks! laurie >>> "Wee Tung" <wtung@us.ibm.com> 12/12/07 3:41 PM >>> The default action when you do cdr check -R is all data on master(serve= r A) will get sync to the slave (server B) and delete the extra rows on serv= er B. If you want the 3 extra rows from server B to send to server A, you nee= d to add --extratargetrows=3Dmerge in cdr check command. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= /com.ibm.erep.doc/erep227.htm ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ = "Laurie Gustin" = <lgustin@utah.gov = > = To ids@iiug.org, Wee = 12/12/2007 03:56 Tung/Lenexa/IBM@IBMUS = PM = cc = Subj= ect Re: ER question [10732] = = = = = = = ok - but I have a question. If the replicate is set up with a conflict of timestamp.. and update anywhere, and it is a master=3DserverA.. then things go wrong and serverA and serverB are out of sync... some rows are inserted on serverB while replication is down when replcation comes back up.. and I do cdr check -R to resync the da= ta in the tables... what happens (or should happen) to the rows inserted= on ServerB? I just did this and it appeared that serverB had 3 extra rows, but rath= er than send them to sererA, the 3 rows were deleted Is this the way it is supposed to work? or am I just doing something wrong? Thanks Laurie Laurie Gustin IT Programmer Analyst Department of Public Safety lgustin@utah.gov 801-965-4410 >>> "Wee Tung" <wtung@us.ibm.com> 12/12/07 1:49 PM >>> Not sure if someone has replied to your question. You probably has defined conflict rule=3D3Dignore in your replication. = In=3D an update anywhere replication, the update row will be discarded if the ro= =3D w does not exist on target (site B). That is for ignore conflict rule resolution. You can manually insert the row in site B. It will be disca= =3D rded by site A and site C as ignore conflict rule kick in. Please find below for the appropriate conflict rule you want for your replication. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= 3D=3D /com.ibm.erep.doc/erep75.htm ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ =3D "FRANK" =3D <yunyaoqu@gmail.c =3D om> =3D To Sent by: ids@iiug.org =3D ids-bounces@iiug. =3D cc org =3D Subj=3D ect ER question [10706] =3D 12/11/2007 02:48 =3D PM =3D =3D =3D Please respond to =3D ids@iiug.org =3D =3D =3D HI, Folks, A question about ER update anywhere implementation. If a row update ( from site C) can not be completed on site B ( because= =3D the corresponding row does not exist at that time, it was originated at= =3D site A and has not arrived at B yet), can we allow the update at B to have another try (e.g., in 5-10 seconds later) instead of just simply abort it? IDS10 UC5, AIX 5.3 Thanks, Frank ***********************************************************************= =3D ******** Forum Note: Use "Reply" to post a response in the discussion forum. =3D ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. = ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Wee, Convert a update to a insert is probably a good solution for us at this situation( I will be glad if there are more..) We never use time-stamp since our sites can never be globally synchronized! Their clocks simply points to different values even if they just resynchronized them hours ago! As I recalled "always"( not "ignore"..) option crashes my engine on ISD10 UC5 AIX5.3 , it gets improved on IDS11? Thanks, Frank On Dec 12, 2007 5:29 PM, Wee Tung <wtung@us.ibm.com> wrote: > Yes. I do understand your problem now. But, there is nothing ER can do = > when > slow network come in place. > I don't think there is a retry logic in place when transaction got abor= > ted > unless the table is locked(by another transaction) and CDR_DSLOCKWAIT i= > s > set. > I'm not sure what is your priority in each ER site setup, but what you = > can > do for problem like this is to setup ER with timestamp conflict resolut= > ion. > Even with slow network, site C update row will get insert into site B a= > nd > when site A insert row arrived at site B, it will get rejected because = > of > the timestamp. > > Hope this help. > ______ > Software Engineer > IBM Information Management > Informix ER IDSQA > wtung@us.ibm.com > 913-599-7234 > __________________________________ > > = > > "FRANK" = > > <yunyaoqu@gmail.c = > > om> = > To > > Sent by: ids@iiug.org = > > ids-bounces@iiug. = > cc > > org = > > Subj= > ect > > Re: ER question [10733] = > > 12/12/2007 03:33 = > > PM = > > = > > = > > Please respond to = > > ids@iiug.org = > > = > > = > > Wee, > > You are the first one replied. Madison must be on vacation. :-( > > When the row to be updated does not exist, The whole transaction will b= > e > aborted ( the update is only part of it ). Aborting whole transaction > is fine with us because we do not want partial result in database. > > If ER gives the failing transaction another opportunity to try ( second= > s > later), it will be done! Because the row is on the way from site A to s= > ite > B ( slower network from A to B, but from A to C to B is fast!). > > Hope I explained the problem. > > Thanks, > Frank > > On Dec 12, 2007 3:49 PM, Wee Tung <wtung@us.ibm.com> wrote: > > > Not sure if someone has replied to your question. > > You probably has defined conflict rule=3D3Dignore in your replication= > .. In=3D > > an > > update anywhere replication, the update row will be discarded if the = > ro=3D > > w > > does not exist on target (site B). That is for ignore conflict rule > > resolution. You can manually insert the row in site B. It will be dis= > ca=3D > > rded > > by site A and site C as ignore conflict rule kick in. > > > > Please find below for the appropriate conflict rule you want for your= > > > replication. > > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= > 3D=3D > > /com.ibm.erep.doc/erep75.htm > > ______ > > Software Engineer > > IBM Information Management > > Informix ER IDSQA > > wtung@us.ibm.com > > 913-599-7234 > > __________________________________ > > > > =3D > > > > "FRANK" =3D > > > > <yunyaoqu@gmail.c =3D > > > > om> =3D > > To > > > > Sent by: ids@iiug.org =3D > > > > ids-bounces@iiug. =3D > > cc > > > > org =3D > > > > Subj=3D > > ect > > > > ER question [10706] =3D > > > > 12/11/2007 02:48 =3D > > > > PM =3D > > > > =3D > > > > =3D > > > > Please respond to =3D > > > > ids@iiug.org =3D > > > > =3D > > > > =3D > > > > HI, Folks, > > > > A question about ER update anywhere implementation. > > > > If a row update ( from site C) can not be completed on site B ( becau= > se=3D > > > > the corresponding row does not exist at that time, it was originated = > at=3D > > > > site A and has not arrived at B yet), can we allow the update at B to= > > > have another try (e.g., in 5-10 seconds later) instead of just simply= > > > abort it? > > > > IDS10 UC5, AIX 5.3 > > > > Thanks, > > Frank > > > > *********************************************************************= > **=3D > > ******** > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > =3D > > > > > > > > > ***********************************************************************= > ******** > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > ***********************************************************************= > ******** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > = > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >
What about writing a script to sync all machines to once central machin= e every hour? I have not seen the crash if use "always apply" option you mentioned ei= ther in 10x or 11x. Did you log the defect with IBM? ______ Software Engineer IBM Information Management Informix ER IDSQA wtung@us.ibm.com 913-599-7234 __________________________________ = "FRANK" = <yunyaoqu@gmail.c = om> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect Re: ER question [10738] = 12/12/2007 04:53 = PM = = = Please respond to = ids@iiug.org = = = Wee, Convert a update to a insert is probably a good solution for us at this= situation( I will be glad if there are more..) We never use time-stamp since our sites can never be globally synchronized! Their clocks simply points to different values even if they just resynchronized them hours ago! As I recalled "always"( not "ignore"..) option crashes my engine on ISD= 10 UC5 AIX5.3 , it gets improved on IDS11? Thanks, Frank On Dec 12, 2007 5:29 PM, Wee Tung <wtung@us.ibm.com> wrote: > Yes. I do understand your problem now. But, there is nothing ER can d= o =3D > when > slow network come in place. > I don't think there is a retry logic in place when transaction got ab= or=3D > ted > unless the table is locked(by another transaction) and CDR_DSLOCKWAIT= i=3D > s > set. > I'm not sure what is your priority in each ER site setup, but what yo= u =3D > can > do for problem like this is to setup ER with timestamp conflict resol= ut=3D > ion. > Even with slow network, site C update row will get insert into site B= a=3D > nd > when site A insert row arrived at site B, it will get rejected becaus= e =3D > of > the timestamp. > > Hope this help. > ______ > Software Engineer > IBM Information Management > Informix ER IDSQA > wtung@us.ibm.com > 913-599-7234 > __________________________________ > > =3D > > "FRANK" =3D > > <yunyaoqu@gmail.c =3D > > om> =3D > To > > Sent by: ids@iiug.org =3D > > ids-bounces@iiug. =3D > cc > > org =3D > > Subj=3D > ect > > Re: ER question [10733] =3D > > 12/12/2007 03:33 =3D > > PM =3D > > =3D > > =3D > > Please respond to =3D > > ids@iiug.org =3D > > =3D > > =3D > > Wee, > > You are the first one replied. Madison must be on vacation. :-( > > When the row to be updated does not exist, The whole transaction will= b=3D > e > aborted ( the update is only part of it ). Aborting whole transaction= > is fine with us because we do not want partial result in database. > > If ER gives the failing transaction another opportunity to try ( seco= nd=3D > s > later), it will be done! Because the row is on the way from site A to= s=3D > ite > B ( slower network from A to B, but from A to C to B is fast!). > > Hope I explained the problem. > > Thanks, > Frank > > On Dec 12, 2007 3:49 PM, Wee Tung <wtung@us.ibm.com> wrote: > > > Not sure if someone has replied to your question. > > You probably has defined conflict rule=3D3D3Dignore in your replica= tion=3D > .. In=3D3D > > an > > update anywhere replication, the update row will be discarded if th= e =3D > ro=3D3D > > w > > does not exist on target (site B). That is for ignore conflict rule= > > resolution. You can manually insert the row in site B. It will be d= is=3D > ca=3D3D > > rded > > by site A and site C as ignore conflict rule kick in. > > > > Please find below for the appropriate conflict rule you want for yo= ur=3D > > > replication. > > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= 3D=3D > 3D=3D3D > > /com.ibm.erep.doc/erep75.htm > > ______ > > Software Engineer > > IBM Information Management > > Informix ER IDSQA > > wtung@us.ibm.com > > 913-599-7234 > > __________________________________ > > > > =3D3D > > > > "FRANK" =3D3D > > > > <yunyaoqu@gmail.c =3D3D > > > > om> =3D3D > > To > > > > Sent by: ids@iiug.org =3D3D > > > > ids-bounces@iiug. =3D3D > > cc > > > > org =3D3D > > > > Subj=3D3D > > ect > > > > ER question [10706] =3D3D > > > > 12/11/2007 02:48 =3D3D > > > > PM =3D3D > > > > =3D3D > > > > =3D3D > > > > Please respond to =3D3D > > > > ids@iiug.org =3D3D > > > > =3D3D > > > > =3D3D > > > > HI, Folks, > > > > A question about ER update anywhere implementation. > > > > If a row update ( from site C) can not be completed on site B ( bec= au=3D > se=3D3D > > > > the corresponding row does not exist at that time, it was originate= d =3D > at=3D3D > > > > site A and has not arrived at B yet), can we allow the update at B = to=3D > > > have another try (e.g., in 5-10 seconds later) instead of just simp= ly=3D > > > abort it? > > > > IDS10 UC5, AIX 5.3 > > > > Thanks, > > Frank > > > > *******************************************************************= **=3D > **=3D3D > > ******** > > > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > > =3D3D > > > > > > > > > *********************************************************************= **=3D > ******** > > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > > > > *********************************************************************= **=3D > ******** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > =3D > > > > ***********************************************************************= ******** > Forum Note: Use "Reply" to post a response in the discussion forum. > > ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =
Wee, We will try to reproduce it. As for LOG defects to IBM, the experience is not great, the problem will be ignored if they ( or some one) can not reproduce it. Thanks, Frank On Dec 12, 2007 6:49 PM, Wee Tung <wtung@us.ibm.com> wrote: > What about writing a script to sync all machines to once central machin= > e > every hour? > > I have not seen the crash if use "always apply" option you mentioned ei= > ther > in 10x or 11x. Did you log the defect with IBM? > ______ > Software Engineer > IBM Information Management > Informix ER IDSQA > wtung@us.ibm.com > 913-599-7234 > __________________________________ > > = > > "FRANK" = > > <yunyaoqu@gmail.c = > > om> = > To > > Sent by: ids@iiug.org = > > ids-bounces@iiug. = > cc > > org = > > Subj= > ect > > Re: ER question [10738] = > > 12/12/2007 04:53 = > > PM = > > = > > = > > Please respond to = > > ids@iiug.org = > > = > > = > > Wee, > > Convert a update to a insert is probably a good solution for us at this= > > situation( I will be glad if there are more..) > > We never use time-stamp since our sites can never be globally > synchronized! Their clocks simply points to different values even if > they just resynchronized them hours ago! > > As I recalled "always"( not "ignore"..) option crashes my engine on ISD= > 10 > UC5 AIX5.3 , it gets improved on IDS11? > > Thanks, > Frank > > On Dec 12, 2007 5:29 PM, Wee Tung <wtung@us.ibm.com> wrote: > > > Yes. I do understand your problem now. But, there is nothing ER can d= > o =3D > > when > > slow network come in place. > > I don't think there is a retry logic in place when transaction got ab= > or=3D > > ted > > unless the table is locked(by another transaction) and CDR_DSLOCKWAIT= > i=3D > > s > > set. > > I'm not sure what is your priority in each ER site setup, but what yo= > u =3D > > can > > do for problem like this is to setup ER with timestamp conflict resol= > ut=3D > > ion. > > Even with slow network, site C update row will get insert into site B= > a=3D > > nd > > when site A insert row arrived at site B, it will get rejected becaus= > e =3D > > of > > the timestamp. > > > > Hope this help. > > ______ > > Software Engineer > > IBM Information Management > > Informix ER IDSQA > > wtung@us.ibm.com > > 913-599-7234 > > __________________________________ > > > > =3D > > > > "FRANK" =3D > > > > <yunyaoqu@gmail.c =3D > > > > om> =3D > > To > > > > Sent by: ids@iiug.org =3D > > > > ids-bounces@iiug. =3D > > cc > > > > org =3D > > > > Subj=3D > > ect > > > > Re: ER question [10733] =3D > > > > 12/12/2007 03:33 =3D > > > > PM =3D > > > > =3D > > > > =3D > > > > Please respond to =3D > > > > ids@iiug.org =3D > > > > =3D > > > > =3D > > > > Wee, > > > > You are the first one replied. Madison must be on vacation. :-( > > > > When the row to be updated does not exist, The whole transaction will= > b=3D > > e > > aborted ( the update is only part of it ). Aborting whole transaction= > > > is fine with us because we do not want partial result in database. > > > > If ER gives the failing transaction another opportunity to try ( seco= > nd=3D > > s > > later), it will be done! Because the row is on the way from site A to= > s=3D > > ite > > B ( slower network from A to B, but from A to C to B is fast!). > > > > Hope I explained the problem. > > > > Thanks, > > Frank > > > > On Dec 12, 2007 3:49 PM, Wee Tung <wtung@us.ibm.com> wrote: > > > > > Not sure if someone has replied to your question. > > > You probably has defined conflict rule=3D3D3Dignore in your replica= > tion=3D > > .. In=3D3D > > > an > > > update anywhere replication, the update row will be discarded if th= > e =3D > > ro=3D3D > > > w > > > does not exist on target (site B). That is for ignore conflict rule= > > > > resolution. You can manually insert the row in site B. It will be d= > is=3D > > ca=3D3D > > > rded > > > by site A and site C as ignore conflict rule kick in. > > > > > > Please find below for the appropriate conflict rule you want for yo= > ur=3D > > > > > replication. > > > > http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=3D= > 3D=3D > > 3D=3D3D > > > /com.ibm.erep.doc/erep75.htm > > > ______ > > > Software Engineer > > > IBM Information Management > > > Informix ER IDSQA > > > wtung@us.ibm.com > > > 913-599-7234 > > > __________________________________ > > > > > > =3D3D > > > > > > "FRANK" =3D3D > > > > > > <yunyaoqu@gmail.c =3D3D > > > > > > om> =3D3D > > > To > > > > > > Sent by: ids@iiug.org =3D3D > > > > > > ids-bounces@iiug. =3D3D > > > cc > > > > > > org =3D3D > > > > > > Subj=3D3D > > > ect > > > > > > ER question [10706] =3D3D > > > > > > 12/11/2007 02:48 =3D3D > > > > > > PM =3D3D > > > > > > =3D3D > > > > > > =3D3D > > > > > > Please respond to =3D3D > > > > > > ids@iiug.org =3D3D > > > > > > =3D3D > > > > > > =3D3D > > > > > > HI, Folks, > > > > > > A question about ER update anywhere implementation. > > > > > > If a row update ( from site C) can not be completed on site B ( bec= > au=3D > > se=3D3D > > > > > > the corresponding row does not exist at that time, it was originate= > d =3D > > at=3D3D > > > > > > site A and has not arrived at B yet), can we allow the update at B = > to=3D > > > > > have another try (e.g., in 5-10 seconds later) instead of just simp= > ly=3D > > > > > abort it? > > > > > > IDS10 UC5, AIX 5.3 > > > > > > Thanks, > > > Frank > > > > > > *******************************************************************= > **=3D > > **=3D3D > > > ******** > > > > > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > > > > > =3D3D > > > > > > > > > > > > > > *********************************************************************= > **=3D > > ******** > > > > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > > > > > > > > > *********************************************************************= > **=3D > > ******** > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > =3D > > > > > > > > > ***********************************************************************= > ******** > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > ************************************************************