Sure but without some fancy work you still have the problem of checkout for modification with pending lock?
What you describe here is a lazy update. The app trying to update has no idea whether it overwrites a previous config change or not.
You could of course request the update message to have the timestamp of the read (which would be the timestamp of the last update). Compare that with the timestamp of the current config record and if there is a discrepancy reject the update returning current state...
Sure but without some fancy work you still have the problem of checkout for modification with pending lock?
Yeah. But I wouldn't consider adding a "read with lock" request message to be fancy work. A "read with lock" request message would instruct the server to change it's next GET to match either the same message ID or correlID or some such to ensure that it only handles the next message from the same client. Kind of a bi-directional request/reply. _________________ I am *not* the model of the modern major general.
Sure but without some fancy work you still have the problem of checkout for modification with pending lock?
Yeah. But I wouldn't consider adding a "read with lock" request message to be fancy work. A "read with lock" request message would instruct the server to change it's next GET to match either the same message ID or correlID or some such to ensure that it only handles the next message from the same client. Kind of a bi-directional request/reply.
Can't do that. In the meantime there are some requesters out there that just want to see the current config. (it has been "checked out" but not updated yet...)...
Best thing might be something like subversion or any other version control system and forget MQ for this stuff... _________________ MQ & Broker admin
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum