single execution of a service

[sandrotosi]

Hi All,
i'm trying to design a solution to let only a single instance of service be running at a given time, let other service execution request be in wait. i mean, a monitor...

I've identified a couple of solution:

1. the "dirty&ugly" one
write a wrapper java flow with a syncronized { ... } block where inside it I'll call the service I need to serialize execution

2. using docs & triggers
a more wM-ish way would be to define a service to publish locally a document that a trigger elaborates in a sequential fashion invoking the single-running service.

I know, that if I'm going to ask you what's better, you'd say the 2nd, but I'd like to here from you some pros&cons on them.

Thanks in advance,
Sandro

[saurabhm]

no point writing "dirty&ugly" code... :eek: write "neat&tidy" code... :biggrin: use option 2 :o

[reamon]

Option 1 doesn't seem dirty and ugly to me. Just be careful about which object or class you synchronize on so that you don't synchronize other unrelated threads.

Out of curiosity, what are you serializing?

[sandrotosi]

Hi Saurab/Rob,
I've decided to do thing the right way, and I've used docs&triggers.

Rob, this is the code I've written into java service to serialized execution:

--Object lock = new Object();
--//only one service at a time will execute this piece of code
----synchronized(lock) {
------<do my stuff here: read service params, invoke service, write output params, etc etc>
----}

The reason to serialize raised because we have a service (let's call it ML, multilaunch) that fires more instance of a task, and each one feedbacks its completion. sometimes, when 2 (or more) completes in the same time, feedbacking at the same moment, ML is waken up twice creating some issues to our integration.

Serializing the simple-task feedback is solving the issue, and doing it with docs&trigs do it in a wM-ish way :)

Thanks both!

[reamon]

It's probably good you went the pub/sub route as the sample Java code you posted will not be effective. That is because each thread will allocate its own lock object and then sync on it. There will be no multi-thread synchronization at all. To get that, you'd need to have a single lock object that all threads use.

[sandrotosi]

Oh damn, you're right! Ok, just to talk: what would I have to do to implement it correctly?

For example, define a

--static Object lock = new Object();

inside "Source" box of "Shared" tab of Java service?

Thanks for the support,
Sandro

[reamon]

That's right.

[sandrotosi]

Hi Rob, I've done that way and it's working! Now I got another "useful" service in our framework... :)

Thanks,
Sandro