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

[James Foster]

Have you measured the time for the second transaction? How often do you expect to have a conflict on the second transaction? If it is rare, then you could include it in the first transaction and then retry the entire request if needed. 

What is “the RabbitMQ way”? Is it simply a way to serialize transactions to avoid commit conflicts? If so, then perhaps you could use an object lock to serialize handling of requests.

James

> On Aug 25, 2022, at 9:13 AM, Marten Feldtmann <m at feldtmann.online> wrote:
> 
> Yes I know, but then there would two 2 commits for each API call - well I try to go the RabbitMQ way for the next projects ...
>  
> Marten
>> James Foster <smalltalk at jgfoster.net> hat am 24.08.2022 10:08 CEST geschrieben:
>>  
>>  
>> 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 <mailto: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 <mailto: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/20220825/b061a16a/attachment-0001.htm>