<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 23, 2022 at 12:36 AM Marten Feldtmann via Glass <<a href="mailto:glass@lists.gemtalksystems.com">glass@lists.gemtalksystems.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>
I've face a problem for years now using Gemstone/S and I did several attempts to solve this, but I would like to ask, if there is a hidden trick to get rid of concurrency in this case using Gemstone/s.
</div>
<div>
</div>
<div>
Think about a session object holding an attribute with a timestamp - a timestamp, where the last successful commit has been done in this session. Its a rough index about how the session hasn't done anything (regarding the read-only user case).
</div></div></blockquote><div><br></div><div>Can you elaborate on how you *use* this timestamp. Most of your message focussed on how and when it gets updated. "a rough index" may mean its precision isn't that important. Is microsecond accuracy essential or important? Millisecond? Single seconds? 10s of seconds?</div><div><br></div><div>If it doesn't need extreme accuracy, you can have the subsequent processes only try to update it if the currently recorded timestamp is older than some threshold. In this way, the first response would update it and the cascade of other requests you describe would ignore it.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div>
</div>
<div>
This session object is shared in a Javascript ui frontend-application (actually the gop to the session) - and now whenever this ui calls an API function on the server (resulting in a commit), the session object in the server gets updated. But if the UI now opens several windows and would like to do sevral independent stuff with the same session in a concurrency way - you will notice, that the API calls might fail - due to concurrency of updating the same timestamp from different "logical" threads.
</div>
<div>
</div>
<div>
How can this be solved in Gemstone/S ? Retry of the transaction just due to this field might be pretty cost intensive.
</div>
<div>
</div>
<div>
How did I try to solve that in the past ?
</div>
<div>
</div>
<div>
a) I added an update object in a work queue and and independent topaz process worked on that work queue
</div>
<div>
</div>
<div>
In a newer attempt I introduced RabbitMQ in our solutions and use RabbitMQ for holding the information formerly stored in the work queue in Gemstone/S and now the topaz process receives information from RabbitMQ and updates the data in an optimized way. The good thing here is, that I get session updates in an transaction with or without commit.
</div>
<div>
</div>
<div>
Any ideas ?
</div>
</div>
_______________________________________________<br>
Glass mailing list<br>
<a href="mailto:Glass@lists.gemtalksystems.com" target="_blank">Glass@lists.gemtalksystems.com</a><br>
<a href="https://lists.gemtalksystems.com/mailman/listinfo/glass" rel="noreferrer" target="_blank">https://lists.gemtalksystems.com/mailman/listinfo/glass</a><br>
</blockquote></div></div>