Blocking queue to serve access tokens


(Richard V) #1

Hello Everyone,

I would like some help with implementing something in Tryton that works like a blocking queue that multiple modules can make a request (posting) to received back an “access tokens” that is later used to access information from a remote server. Basically, I have a worker that queries a remote server for access token when needed and stores it into the DB so that it can be shared among different modules. The request and storing of this token is done only by this worker only. Eventually the token may expire and needs to be renewed / refreshed but only if it needs to (i.e. there are modules requesting information from the remote server). I know Tryton 5.0 has a queue that uses postgresql listen/notify feature to allow modules to send “requests / tasks” to be handled by a worker. However this queue is non-blocking; for my specific access token use case, I need the module’s token request to block and wait for response from the worker. If the worker has an available token, it will response back to the module quickly; if the token is expired, the worker will have to renew it, hence the rest of the modules must wait until it becomes available.

Can someone point me how can this be implemented in Tryton?

Many thanks in advanced.


(Nicolas Évrard) #2

You already have this part of the code? If so is it implemented in Tryton?

You should probably use a locking mechanism.


(Cédric Krier) #3

I think you do not need to have a worker but simply a service/method that takes a lock (to ensure sequential access) on a table on each call and you store the token into this table.


(Richard V) #4

If I use a table lock, wouldn’t it become a scaling limitation? Pardon my ignorance, can postgresql lock a record instead of a table?


(Richard V) #5

Thank you Nicolas and Cédric for the suggestions. I will use postgres “select for update” to lock the row to achieve the sequential access. I will borrow a similar code found in ir/sequence.py.


(Cédric Krier) #6

Yes but it is not the problem of lock, it is your requested design.

I does not prevent concurrent creation if no record exists.


(Richard V) #7

I will make sure that from the beginning when the module is installed for the first time that there is always one record created by default.