How to make a service Single Threaded/Synchronous in cluster

, ,
1

Hi,

I have a requirement where multiple instances of a business process need to call a java service which must be synchronous (single threaded) which means while the one of the instance is calling that service than other instances must wait in a queue. Because i need to append create a unique file name using the dateTime stamp. we are not having any problem when we are running this on a non clustered environment as we are using the synchronised block in java service, just worried of that when we run this process on a clustered environment as there is chance of both servers in the cluster can generate the same dateTime stamp which proceeds create a same file name in both the servers. Please can any one provide me solution to overcome this.

Regards,
Srinivas Kotturi.

2

I believe you can use “Singleton” Pattern.

Singleton ensure a class has one instance and provide a global point of access to it.

3

Hi Srinivas,

I believe if your issue is to have unique file name, then you should work on creating unique name instead of making service synchronous. To make file name unique you can write java service to give you randon number and put that in file name or use ContextID of webMethods and put in file name.

I believe you are looking your problem wrong way…:slight_smile:

Cheers,
Ajit

4

Hi Ajit,

Thankyou for the reply. Let me make you clear on my situation. The business requiremnet is to have a DateTimeStamp some thing like('D’yyMMdd’T’hhmmss) as the file name. As our production evnvironment is a cluster of 2 servers, there is always a chance of both the servers can generate the dupilcate file name with same Date Time stamp. So cosnidering this pls advise me on this.

Regards,
Srinivas Kotturi.

5

Srinivas,

Here’s a couple of options:

  1. Do synchronisation using the pub.storage services in WmPublic. These services can do synchronised reads on the repository, which is shared in a clustered environment (assuming your cluster is configured correctly to use external repo servers). Create a storage item and make each process read (and lock) the item before your synchronised section, and then release the lock afterwards. If a second instance tries to get the lock while the first is running (even across a cluster), it will automatically wait until the lock is released.

OR

  1. Make the synchronised part of your process started by a trigger subscribing to a Broker document. If you then set the trigger properties to be Serial (instead of concurrent), then this will ensure that document sequencing is maintained, even across the cluster. The next document in the queue will not be passed to either cluster node until the previous one has been fully processed.

Hope this helps.

Jonathan Heywood
webMethods Professional Services

6

Srinivas,

Does the business requirement restrict the exact naming of the file? Must the file be named only with the timestamp or can you have other bits of information?

Depending on the size and volume of messages, the timestamp is potentially not enough to provide uniqueness–the smallest time resolution you can get is the millisecond range. Receiving many documents has the potential for collision even in a non-clustered environment!

That aspect aside adding some text specific to each server gets you half way there e.g. server1.xml and server2.xml.

You’ll need to look at your expected volume to determine whether the issue above applies to you.

Cheers!

Ed