How to strictly serialize MII TXs

[Former Member]

Hi All,

how can MII transactions strictly be serialized? I recognized that sceduled TXs are fired through JMS queues. Is there a way to limit the

MII MDB to 1 instance? What is when several MII processes are run? Also the issue we face is that we have a scheduled TX that wil also

be triggered by user interaction. So parallel execution happens from time to time. Any solutions?

Thanks,

Matthias

[Former Member]

One option would be to create your own queue and your own "worker" transaction. The other transactions would simply prepare the request and add the request to a queue (perhaps with all relevant data and parameters passed in an XML file), and the "worker" would process them one at a time in sequential order (the worker would need to be scheduled as well). However, this would not provide immediate execution in the case of user-initiated invocations, if that was needed.

Alternatively, you could use a tag in the simulator server (or create a custom action) that acts as an in-memory flag or semaphore that can be used to ensure that only one instance of a transaction ever executes at a time.

[Former Member]

Hi Rick,

I would prefer the custom action solution. Altough it would be best to have support from the MII development team also. Maybe two actions "aquireGlobalLock" and "releaseGlobalLock" could be provided. Locking could be done on DB via serializeable isolation level. As one can lock on a db record, different locks could be configured with for example lock name and description which could be used from the actions.

What do you think?

[Former Member]

That should work, but I'd also provide some monitoring infrastructure (so you can see which locks are active) and a UI for forceably releasing them in case of odd behavior or on system startup...

[Former Member]

Hi Rick,

the monitoring system could only rely on information from the custom actions. Or the actions could write monitoring information into an additional table, although it would make trouble in case of crashes were the locks will go but the monitoring information will not be cleaned up. Locks would anyway be released with the db connections (it's just an select for update), so clean up code for db connections should do it.