<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div class="default-style">
The first transaction does the business logic, so its time consuming and conflicts should be avoided whenever you can (to avoid retries).
</div>
<div class="default-style">
</div>
<div class="default-style">
When starting the API way development here with Javascript in the UI, the JS developer spawned requests to the server (in the same session, but from different points in the application) and conflicts were pretty often. We have solved this by ensuring, that all the API calls from Javascript (Ajax requests) are serialized in some way and so we got rid of this problem. But from the perspective of a JS developer this is bad style.
</div>
<div class="default-style">
</div>
<div class="default-style">
The RabbitMQ way is, that after each final commit or abort in Gemstone/S the server is now able to send events to RabbitMQ (an event may be sent on success or failure case, or always). These events are collected during the work of an API call into the Gemstone server. Another events are: log messages, domain object changes (user data has changed e.g.) and many more ... external processes in other languages (or topaz) will do some work based on these events/messages. And you may assume, that hundreds of these events (each minute) can be fired in a full application.
</div>
<div class="default-style">
</div>
<div class="default-style">
So one of these events are SessionActivity Events ... and a topaz process is receiving the events from RabbitMQ and is collecting all these events , optimzes the updates in the databases etc...
</div>
<div class="default-style">
</div>
<div class="default-style">
These processes do not need to be written in topaz (because then the number of working tasks using topaz would be increasing as well and regarding the smaller $1500/$3000 license restrictions .... it would be better to use other languages to do the work.).
</div>
<div class="default-style">
</div>
<div class="default-style">
Normally we do such work in python (or with more speed C#) - over the last two month I made VASTPlatform working again with our API definitions so this would be a candidate too - but python is much , much handier and has more external solutions available doing various stuff.
</div>
<div class="default-style">
</div>
<div class="default-style">
Earlier we did this via ZMQ, but now with the RabbitMQ Connect we have a better buffer and the first experiences are very good.
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<div class="default-style">
</div>
<blockquote type="cite">
<div>
James Foster <smalltalk@jgfoster.net> hat am 25.08.2022 09:39 CEST geschrieben:
</div>
<div>
</div>
<div>
</div> 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="">
</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="">
</div>
<div class="">
James
<br class="">
<div>
<br class="">
<blockquote type="cite">
<div class="">
On Aug 25, 2022, at 9:13 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="">
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 class="">
James Foster <<a class="" href="mailto:smalltalk@jgfoster.net">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">
<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>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>