[Glass] Class var and class inst var caches in libraries

[Paul Baumann via Glass]

Use application design that provides division of responsibility. Avoid
having more than one gem updating the same value holder. Gem-specific value
holders can be used, referenced in gem-specific dictionary (or object).
Any other gems can query committed assignments of others to find consensus.
Somewhat like an rc collection implementation, and similar to chain of
responsibility design pattern.

One technique is to add an instruction object to an RcQueue that a single
manager processes in a separate dedicated gem. Many gems give instructions,
and one manager processes them without conflicts. Gem-to-gem signaling can
be part of that design if delay loops are not desired or timely. Nested
transactions might come in handy for this now that gs has them. The commits
and aborts used for queued work may not be ideal for some applications.

There are many tricks and techniques, the most appropriate depends on your
application needs. Review the RC collections to see if any help you. Your
application code needs to have a strategy to avoid conflicts though.
Locking can be avoided for most code. It seems odd that your code has
multiple gems updating the same class variables.

Paul Baumann
On Oct 4, 2016 2:56 PM, "monty via Glass" <glass at lists.gemtalksystems.com>
wrote:

> Lots of libraries use caches stored in class vars and class isnt vars that
> are either explicitly or lazily initialized. But with multiple Gems
> accessing the same repo, this can produce write-write conflicts. In fact,
> simply sending #initialize to the same class from different Gems can cause
> them. What are the best ways to implement these caches in GS? Write-locks
> seem like overkill, so I'm interested in simple ways of making them
> non-persistent.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20161008/2473e21d/attachment-0001.html>