For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

izlatanov_27396's avatar
izlatanov_27396
Icon for Nimbostratus rankNimbostratus
Jun 27, 2016

Concurrent transactions in different sessions by single user

Hello,   We are happily using sessions to isolate active folder setting in concurrent requests issued by the same user. However, if we introduce transactions in the concurrent requests, submit_tra...
BIG-IP
cloud
iControl
session
transaction
Joe_Pruitt's avatar
Joe_Pruitt
Jul 06, 2016

I believe the transaction is stored as a session variable for the given user's context on the server. If you have two parallel sessions with the same user using transactions, the first call to submit_transaction() will proceed and delete the transaction id. If you call it a second time from the other session, it will likely fail as the transaction id has been removed by the first call. The only real solutions is to use the locking mechanism in the System.SystemInfo interface. The first session can acquire a lock and then perform it's transaction. The second session will attempt to acquire a lock and wait until one is available and then lock it's attempt at a transaction. I wrote about those interfaces in the article on Concurrent iControl Programming - https://devcentral.f5.com/articles/concurrent-icontrol-programming-explained.

 

The other option is to use multiple user accounts.