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

[James Foster]

I interpret you to say that this is an “application” session object that can be updated from several gems. Is there a reason you don’t do an abort before processing the client update?

> On Aug 23, 2022, at 9:37 PM, Marten Feldtmann <m at feldtmann.online> wrote:
> 
> Its a Gemstone/S object, which is created after an application has been connected (logged in) to the server via my application API. This API is the connection from Gemstone/S to all the other clients running around, written in Python, C#, Java or Javascript.
>  
> Each application sends the gop of its "session" with each request ... to the server and there are lots of http topaz based server tasks waiting for requests.
>  
> Under SQL this problem can be solved without any problems - but under Germstone/S this "simple" problem is difficult to solve: it can be reduced to the question - can an object be updated  but changes at one specific attribute should not be taken into account when calculating concurrency situation.
>  
> Marten
>> James Foster <smalltalk at jgfoster.net <mailto:smalltalk at jgfoster.net>> hat am 23.08.2022 09:45 CEST geschrieben:
>>  
>>  
>> Marten,
>>  
>> Could you clarify your use of the word “session”? Is this an application session that crosses several Gems or is it a GemStone session (a single Gem)?
>>  
>> James
>>  
>>> On Aug 23, 2022, at 9:31 AM, Marten Feldtmann via Glass <glass at lists.gemtalksystems.com <mailto: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).
>>>  
>>> 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 <mailto:Glass at lists.gemtalksystems.com>
>>> https://lists.gemtalksystems.com/mailman/listinfo/glass <https://lists.gemtalksystems.com/mailman/listinfo/glass>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20220823/8f68afb5/attachment.htm>