[Glass] How to solve this problem - concurrency on one field/attribute

[Richard Sargent]

On Tue, Aug 23, 2022 at 12:36 AM Marten Feldtmann via Glass <
glass at lists.gemtalksystems.com> wrote:

> 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.
>
> 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).
>

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?

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.



>
> 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.
>
> How can this be solved in Gemstone/S ? Retry of the transaction just due
> to this field might be pretty cost intensive.
>
> How did I try to solve that in the past ?
>
> a) I added an update object in a work queue and and independent topaz
> process worked on that work queue
>
> 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.
>
> Any ideas ?
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20220823/3bf2f8bb/attachment.htm>