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 Message Broker (ACE) Support » How to Make An XML Update Operation Single-threaded

Post new topic  Reply to topic
 How to Make An XML Update Operation Single-threaded « View previous topic :: View next topic » 
Author Message
wmbv7newbie
PostPosted: Sat Aug 22, 2015 7:40 pm    Post subject: How to Make An XML Update Operation Single-threaded Reply with quote

Centurion

Joined: 13 May 2014
Posts: 121

Hi,

We are working on a solution to minimise logging into an application multiple times. The idea is to login to the target system (Salesforce) once, save the sessionId to a cache xml (basically an xml file on the server with logging-in details as name-value pairs for multiple users) and use it for subsequent calls. When the sessionId expires, login to SFDC again, get a new sessionId, update the cache xml value and continue processing.

We were thinking to use Java for the "updating cache xml with new sessionId" part of the solution. However, we are stuck at how to make this update operation single-threaded (I might be using the wrong term here, so giving an example to explain in detail). Consider below scenario -

Suppose there are two different operations running at the same time to use SFDC (for e.g. queryOrderById and getUserInfo). Both found at the same time that the sessionId in cache has expired. So, both try to get new sessionId at the same time. Till this point, it is fine. But then both try to update the cache xml with new value at the same time. This might be an issue. So, we wanted to make the Java application which is responsible for updating the xml as single-threaded application so that only one instance can use it at a time and others are blocked until it completes. But we dont know how to achieve this. Any hints would help.

Any other alternative ideas to accomplish this is also welcome.

Other details -
1. We are using IIB V9 with MQ 7.5.0.3
2. Global cache is not an option at the moment. However, we might consider it later for the solution, as it involves extra settings and config on the servers, for which we dont have enough time right now. If nothing else works, of course we will go for it

Thanks in advance!
Back to top
View user's profile Send private message
smdavies99
PostPosted: Sat Aug 22, 2015 9:49 pm    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

How about something like
ESQL Shared variable with updates controlled using an ATOMIC block?
Have the ESQL Function/.Procedure where this is done used by ALL the flowns that need the locking. With the Atomic block only one thread can execute it at a time. This solves the problem where you have multiple instances of the flow running.

The ESQL Shared variable is not broker wide though. It is only EG wide.

If you want a Broker wide solution then you may well have to go with the Global Cache.

I am sure that there are other solutions.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
wmbv7newbie
PostPosted: Sat Aug 22, 2015 11:42 pm    Post subject: Reply with quote

Centurion

Joined: 13 May 2014
Posts: 121

For now, we have implemented the UDP way in ATOMIC Block as an interim solution, as we were getting locked out due to >3.2K login attempts every hour. But this wont work for long-term, as we might have multiple user login details (identified by Org Ids related to the multiple SFDC environments) and we want our code to be flexible enough to handle all.
Also, in this case, everytime we get a new OrgId, we will have to touch our code, which we dont want to do.
By using the xml file, we just have to modify that for a new OrgId.

For single thread, I was reading about additional instances at flow and node level. Any idea if it will work in case I put additional instances to 0 (which is the default value)?
Or if we have something equivalent of ATOMIC in Java?

Reference -
Quote:
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.scenarios.doc/UnderstandingSubflows/Topics/scnsubflows_01_28_.htm?cp=SSKM8N_8.0.0%2F1-2-0-0-1-3-5-0


Quote:
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.scenarios.doc/UnderstandingSubflows/Topics/scnsubflows_01_30_.htm?cp=SSKM8N_8.0.0%2F1-2-0-0-1-3-5-1
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Aug 23, 2015 1:36 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

You could just as well update the xml in the ATOMIC block...
Think if you have to use java, use the synchronized modifier. Google it.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
wmbv7newbie
PostPosted: Mon Aug 24, 2015 8:32 pm    Post subject: Reply with quote

Centurion

Joined: 13 May 2014
Posts: 121

Thanks! Synchronized works good for me
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 Message Broker (ACE) Support » How to Make An XML Update Operation Single-threaded
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.