ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Interchange Server + Adapters » Synchronization issue with ICS

Post new topic  Reply to topic
 Synchronization issue with ICS « View previous topic :: View next topic » 
Author Message
anveshita
PostPosted: Thu Feb 22, 2007 7:08 pm    Post subject: Synchronization issue with ICS Reply with quote

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
View user's profile Send private message
mqseries0209
PostPosted: Wed Mar 14, 2007 5:58 am    Post subject: hi Reply with quote

Voyager

Joined: 30 Mar 2006
Posts: 90

Did you find any solution for the problem?.
Back to top
View user's profile Send private message
voyager
PostPosted: Fri Mar 16, 2007 6:01 am    Post subject: Kinda Reply with quote

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
View user's profile Send private message
mqseries0209
PostPosted: Thu Mar 22, 2007 8:07 am    Post subject: Reply with quote

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
View user's profile Send private message
voyager
PostPosted: Tue Mar 27, 2007 7:03 am    Post subject: Reply with quote

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
View user's profile Send private message
mqseries0209
PostPosted: Wed Mar 28, 2007 6:44 am    Post subject: Reply with quote

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
View user's profile Send private message
voyager
PostPosted: Wed Apr 04, 2007 5:54 am    Post subject: Reply with quote

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
View user's profile Send private message
Kram
PostPosted: Thu Apr 26, 2007 10:08 am    Post subject: Reply with quote

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
View user's profile Send private message
mqseries0209
PostPosted: Fri Apr 27, 2007 7:42 am    Post subject: Reply with quote

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
View user's profile Send private message
Kram
PostPosted: Fri Apr 27, 2007 11:49 am    Post subject: Reply with quote

Voyager

Joined: 02 Mar 2006
Posts: 87

Can you explain why its not a practical option.
_________________
Regards,
Ram
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Interchange Server + Adapters » Synchronization issue with ICS
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.