<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">James<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 25, 2022, at 9:13 AM, Marten Feldtmann <<a href="mailto:m@feldtmann.online" class="">m@feldtmann.online</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta charset="UTF-8" class="">
<div class="">
<div class="">
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" class="">
<div class="">
James Foster <<a href="mailto:smalltalk@jgfoster.net" class="">smalltalk@jgfoster.net</a>> hat am 24.08.2022 10:08 CEST geschrieben:
</div>
<div class="">
</div>
<div class="">
</div> That looks very good (and similar to what is done with the GemStone implementation of Seaside).
<br class="">
<div class="">
<br class="">
<blockquote type="cite" class="">
<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" class="">
<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" class="">
<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" class="">
<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" class="">
<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>
</div>
</div></blockquote></div><br class=""></div></body></html>