on 03-29-2008 7:48 AM
Hi.
The case is, that a transaction can run twice or more, if started at the same time. Is it possible to avoid this, e.g. by checking at the top of the transaction if another instance is running?
E.g. if I schedule a transaction to run every 1 minute, and it by any chance does not complete within time, another instance is started.
BR.
Poul.
Poul,
A transaction running in the scheduler should not overtake a currently running instance, meaning that if your TRX takes longer than 1 minute to run it will not reset the 1 minute interval until it has completed. If you are seeing this sort of behavior then please advise.
Regards,
Jeremy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Jeremy.
Meaning that the next run time will be updated when a transaction has completed?
I have seen it, but I started the transaction from schedule editor manual.
BR.
Poul.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rick.
I was thinking about some in this direction, but did hope for some easier way.
The case is, that if two instances of the same transaction catches the same XML, to times data are entered into SAP. So I need some bulletprof way of doing this.
Deleting the XML will cause me problems with my error handling, but could be a solution also.
An other idea could be to use queue system, but in this case I need a "check out" action block.
This is input for future impovement of xMII.
BR.
Poul.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello, Poul.
There's no "built-in" technique for this, but you could use a few different techniques for achieving this. You'll need some type of "persistent" (or at least "memory persistent") place to save away the status of the transaction.
One trick to doing this is to use the Simulator server. You can create your own read/write "tags" in the Simulator that can be used to store in-memory state. You can then use the Current and CurrentWrite modes in a tag query to read/write these value(s).
At the top of your transaction, you could write a value indicating that the transaction was active and at the end of the transaction you could reset/clear it.
You could also use a database table or other mechanism to achieve the same result.
Best regards,
Rick
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
4 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.