<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   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 ...
  </div> 
  <div class="default-style">
    
  </div> 
  <div class="default-style">
   Marten
  </div> 
  <blockquote type="cite"> 
   <div>
    James Foster <smalltalk@jgfoster.net> hat am 24.08.2022 10:08 CEST geschrieben:
   </div> 
   <div>
     
   </div> 
   <div>
     
   </div> That looks very good (and similar to what is done with the GemStone implementation of Seaside).
   <br class=""> 
   <div>
    <br class=""> 
    <blockquote type="cite"> 
     <div class="">
      On Aug 24, 2022, at 9:48 AM, Marten Feldtmann <<a class="" href="mailto:m@feldtmann.online">m@feldtmann.online</a>> wrote:
     </div> 
     <br class="Apple-interchange-newline"> 
     <div class=""> 
      <div class=""> 
       <div class="">
        Hello James,
       </div> 
       <div class="default-style">
         
       </div> 
       <div class="default-style">
        well one way would be to do:
       </div> 
       <div class="default-style">
         
       </div> 
       <div class="default-style">
        Client => Server (sends request)
       </div> 
       <div class="default-style">
        Server gets the request
       </div> 
       <div class="default-style">
        abortTransaction
       </div> 
       <div class="default-style">
        begin Transaction
       </div> 
       <div class="default-style">
        <do the stuff to do in gemstone server data structure>
       </div> 
       <div class="default-style">
        commtTransaction (if this fails, retry the block>
       </div> 
       <div class="default-style">
        begin transaction
       </div> 
       <div class="default-style">
        <update the timestamp>
       </div> 
       <div class="default-style">
        commitTransaction (if this fails do not care)
       </div> 
       <div class="default-style">
        abortTransaction
       </div> 
       <div class="default-style">
        Server => Client (send the answer)
       </div> 
       <div class="default-style">
         
       </div> 
       <blockquote type="cite"> 
        <div class="">
         James Foster <<a class="" href="mailto:smalltalk@jgfoster.net">smalltalk@jgfoster.net</a>> hat am 23.08.2022 21:52 CEST geschrieben:
        </div> 
        <div class="">
          
        </div> 
        <div class="">
          
        </div> 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? 
        <br class=""> 
        <div class="">
         <br class=""> 
         <blockquote type="cite"> 
          <div class="">
           On Aug 23, 2022, at 9:37 PM, Marten Feldtmann <<a class="" href="mailto:m@feldtmann.online">m@feldtmann.online</a>> wrote:
          </div> 
          <br class="Apple-interchange-newline"> 
          <div class=""> 
           <div class=""> 
            <div class="">
             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.
            </div> 
            <div class="default-style">
              
            </div> 
            <div class="default-style">
             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.
            </div> 
            <div class="default-style">
              
            </div> 
            <div class="default-style">
             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.
            </div> 
            <div class="default-style">
              
            </div> 
            <div class="default-style">
             Marten
            </div> 
            <blockquote type="cite"> 
             <div class="">
              James Foster <<a class="" href="mailto:smalltalk@jgfoster.net">smalltalk@jgfoster.net</a>> hat am 23.08.2022 09:45 CEST geschrieben:
             </div> 
             <div class="">
               
             </div> 
             <div class="">
               
             </div> 
             <div class="">
              Marten,
             </div> 
             <div class="">
               
             </div> 
             <div class="">
              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)?
             </div> 
             <div class="">
               
             </div> 
             <div class="">
              James
             </div> 
             <div class="">
               
             </div> 
             <blockquote type="cite"> 
              <div class="">
               On Aug 23, 2022, at 9:31 AM, Marten Feldtmann via Glass <<a class="" href="mailto:glass@lists.gemtalksystems.com">glass@lists.gemtalksystems.com</a>> wrote:
              </div> 
              <div class="">
                
              </div> 
              <div class="">
               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 class="">
                
              </div> 
              <div class="">
               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 class="">
                
              </div> 
              <div class="">
               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 class="">
                
              </div> 
              <div class="">
               How can this be solved in Gemstone/S ? Retry of the transaction just due to this field might be pretty cost intensive.
              </div> 
              <div class="">
                
              </div> 
              <div class="">
               How did I try to solve that in the past ?
              </div> 
              <div class="">
                
              </div> 
              <div class="">
               a) I added an update object in a work queue and and independent topaz process worked on that work queue
              </div> 
              <div class="">
                
              </div> 
              <div class="">
               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 class="">
                
              </div> 
              <div class="">
               Any ideas ?
              </div> 
              <div class="">
               _______________________________________________
              </div> 
              <div class="">
               Glass mailing list
              </div> 
              <div class="">
               <a class="" href="mailto:Glass@lists.gemtalksystems.com">Glass@lists.gemtalksystems.com</a>
              </div> 
              <div class="">
               <a class="" href="https://lists.gemtalksystems.com/mailman/listinfo/glass" target="_blank" rel="noopener">https://lists.gemtalksystems.com/mailman/listinfo/glass</a>
              </div> 
             </blockquote> 
            </blockquote> 
           </div> 
          </div> 
         </blockquote> 
        </div> 
       </blockquote> 
      </div> 
     </div> 
    </blockquote> 
   </div> 
  </blockquote>
 </body>
</html>