Author |
Message
|
anveshita |
Posted: Thu Feb 22, 2007 7:08 pm Post subject: Synchronization issue with ICS |
|
|
Master
Joined: 27 Sep 2004 Posts: 254 Location: Jambudweepam
|
System setup:
We are synchronizing two systems (databases) in real time using Websphere MQ and WebSPhere InterChange Server. Our current architecture has two ICS servers with the same set of objects on each server running in parallel. Both servers (ICS1 and ICS2) process the transactions coming from system A and synchronize the system B. We are using MQ as source connector and JDBC as destination connector. We have different set of connectors with same configuration on ICS1 server and ICS2 server.This redundant server configuration is set-up for load sharing purpose only.
Out of synchronization scenario:
System B is getting out of synchronized from system A.
For example: When a particular record on system A produces transactions such as BO1.Create, BO1.Delete. These two transactions namely BO1.Create and BO1.Delete get processed by both ICS1 and ICS2 in parallel. As MQ connector agents on both servers will be polling messages from the same MQ queue, ICS1 server get BO1.Create transaction and ICS2 server get BO1.Delete transaction.
BO1.Delete transaction is getting processed by ICS2 server before BO1.Create transaction gets processed by ICS1 server. Hence, the corresponding record gets deleted from system A, but the same record still exists on System B.
Following are my questions:
1. Definitely we have a problem and we would like our transactions to be processed by the ICS servers in the order in which they are fed. That means if a create transaction enters the system first, then we would like the create transaction to get processed first no matter which ICS server polls it first. Can anyone please suggest a solution to this issue? |
|
Back to top |
|
 |
mqseries0209 |
Posted: Wed Mar 14, 2007 5:58 am Post subject: hi |
|
|
 Voyager
Joined: 30 Mar 2006 Posts: 90
|
Did you find any solution for the problem?. |
|
Back to top |
|
 |
voyager |
Posted: Fri Mar 16, 2007 6:01 am Post subject: Kinda |
|
|
 Centurion
Joined: 28 Dec 2004 Posts: 127
|
I am kinda working on this issue right now. javascript:emoticon(' ')
javascript:emoticon(' ')
This is what I am doing to solve this synchronization issue.
I am planning to distribute the collaborations among two servers and use single thread model on the collaborations instead of multi-threading.
I may have to compromise little bit on performance. But, I think this would mitigate the synchronization issue.
Thanks! _________________ voyager |
|
Back to top |
|
 |
mqseries0209 |
Posted: Thu Mar 22, 2007 8:07 am Post subject: |
|
|
 Voyager
Joined: 30 Mar 2006 Posts: 90
|
hey Voyager,
I am not sure how the java script and single threaded model of collab will work work together to solve the above mentioned issue.
I think threads are for improving performance by making the collab code availabe for mutiple execution at the same time. (correct me if I am wrong)
Even if the collabs are single threaded, The first Instance of ICS, say A might execute delete transaction first then the second ICS instance B executing Create (assuming Create entering the queue first).
The issue is the ICS instances should execute the transactions in the order the requests are arrived on queue.
Can you make your planning more detailed?.
thanks. |
|
Back to top |
|
 |
voyager |
Posted: Tue Mar 27, 2007 7:03 am Post subject: |
|
|
 Centurion
Joined: 28 Dec 2004 Posts: 127
|
Thank you !
mqseries0209 for your comments!
By the way, we are not using java script.
We have two ICS instances processing two different sets of collaborations.
Since, we have two different sets of collaborations, there is no question of event A.Delete would get
processed prior to A.Create as the collaboration event A is on Server instance ICS1.
ICS2 processes a different event
B.Create, B.Delete etc., coming from an event B. (This is independent of event A processed by ICS1)
It is true that multi-Threading on collaborations and Maps is for increasing performance.
It seems that event sequencing is not guaranteed in the case of multi-threading when
the same events are getting processed by two different ICS instances.
By having two different ICS instances process two different events (event transactions)
we can eliminate the issue of event sequencing out of synchronization issues.
Thanks! _________________ voyager |
|
Back to top |
|
 |
mqseries0209 |
Posted: Wed Mar 28, 2007 6:44 am Post subject: |
|
|
 Voyager
Joined: 30 Mar 2006 Posts: 90
|
Quote: |
By the way, we are not using java script.
We have two ICS instances processing two different sets of collaborations.
|
When u use two different sets of collaborations, how do u address FAILOVER and HA issues ? just curios. |
|
Back to top |
|
 |
voyager |
Posted: Wed Apr 04, 2007 5:54 am Post subject: |
|
|
 Centurion
Joined: 28 Dec 2004 Posts: 127
|
We have not yet implemented this in production because we have to forgo "FAILOVER" and HA aspects.
Thank you! _________________ voyager |
|
Back to top |
|
 |
Kram |
Posted: Thu Apr 26, 2007 10:08 am Post subject: |
|
|
Voyager
Joined: 02 Mar 2006 Posts: 87
|
The easiest way to resolve this issue is to stop polling from one of the ICS server (Stop the MQ Adapter from polling...), in that way the traffic is routed to one instance.
Increase the number of threads to keep event sequencing turned ON on the entire flow. (minimize performance issue..).
Incase the running instance of the ICS goes down, manually start the other Adapter...
I assume this should resolve your problem. _________________ Regards,
Ram |
|
Back to top |
|
 |
mqseries0209 |
Posted: Fri Apr 27, 2007 7:42 am Post subject: |
|
|
 Voyager
Joined: 30 Mar 2006 Posts: 90
|
Quote: |
The easiest way to resolve this issue is to stop polling from one of the ICS server (Stop the MQ Adapter from polling...), in that way the traffic is routed to one instance.
Increase the number of threads to keep event sequencing turned ON on the entire flow. (minimize performance issue..).
Incase the running instance of the ICS goes down, manually start the other Adapter...
I assume this should resolve your problem.
_________________
Regards,
Ram |
What you said is not a practical option because of the reason menstioned earlier in the same post. |
|
Back to top |
|
 |
Kram |
Posted: Fri Apr 27, 2007 11:49 am Post subject: |
|
|
Voyager
Joined: 02 Mar 2006 Posts: 87
|
Can you explain why its not a practical option. _________________ Regards,
Ram |
|
Back to top |
|
 |
|