[Glass] How to solve this problem - concurrency on one field/attribute
Lourens van Nieuwenhuizen
LvNieuwenhuizen at momentum.co.za
Tue Aug 23 00:53:34 PDT 2022
What about System>>millisecondsSinceTransactionBoundary?
From: Glass <glass-bounces at lists.gemtalksystems.com> On Behalf Of Marten Feldtmann via Glass
Sent: Tuesday, 23 August 2022 09:31
To: via Glass <glass at lists.gemtalksystems.com>
Subject: [Glass] How to solve this problem - concurrency on one field/attribute
Please note this email originated from external. Please treat with caution.
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).
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 ?
This electronic message, including any attachments, is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you are not the intended recipient, please notify us immediately by replying to this message and then delete this message from your system. Any use, dissemination, distribution or reproduction of this message or any attachments by unintended recipients is unauthorised and may be unlawful. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to perform your own virus checks on any attachment to this message. We do not accept liability for any loss or damage caused by software viruses.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glass