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

[James Foster]

That looks very good (and similar to what is done with the GemStone implementation of Seaside).

> On Aug 24, 2022, at 9:48 AM, Marten Feldtmann <m at feldtmann.online> wrote:
> 
> Hello James,
>  
> well one way would be to do:
>  
> Client => Server (sends request)
> Server gets the request
> abortTransaction
> begin Transaction
> <do the stuff to do in gemstone server data structure>
> commtTransaction (if this fails, retry the block>
> begin transaction
> <update the timestamp>
> commitTransaction (if this fails do not care)
> abortTransaction
> Server => Client (send the answer)
>  
>> James Foster <smalltalk at jgfoster.net> hat am 23.08.2022 21:52 CEST geschrieben:
>>  
>>  
>> 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 <mailto: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/20220824/a098a952/attachment.htm>