[Glass] protect temporary files

[James Foster]

Hi Otto,

As you found, a Semaphore cannot be committed; it is designed to be used only in a single Gem.

To communicate between Gems you have several options. Probably the simplest is to use the existing transaction semantics (which solves the data race problem) to set or clear a flag. So instead of committing a Semaphore you commit a simple Boolean (where true is “in use” or “available” depending on your style).  While this is simple and clear, it has the drawback of requiring a transaction to set and a transaction to clear (which may be unnecessary overhead).

An alternative is to use GemStone’s built-in locks as a mutex. You can obtain and release a lock independent of transactions, so this has less overhead. Of course, you are relying on “convention” to ensure that everyone who needs the lock obtains it but if you have only one code path (“critical section”) that you are trying to protect, then this is fine.

There are other ways of communicating between Gems, but the above is probably best.

James

> On Jun 2, 2023, at 5:09 AM, Otto Behrens via Glass <glass at lists.gemtalksystems.com> wrote:
> 
> Hi,
> 
> We have zipped files (references stored in GemStone with MAExternalFileModel) that we use in an operation, for example to merge PDF data (with PDFTk) or serve to the user via the web server, while it is temporarily unzipped. The code is something like this:
> 
> operation: aBlock
>   tempFile := f unzip.
>   ^ [ aBlock value: tempFile ] ensure: [ tempFile remove ]
> 
> We have on occasion multiple sessions that do operations on the same file, which causes a problem. We would like to protect the operation with a semaphore or something like that.
> 
> Is a Semaphore the way to solve this or is there a better alternative?
> 
> If we use Semaphore and store it on our file object, we cannot commit because we cannot persist the semaphore instVar. According to the programming guide, "if you need to encapsulate objects that should not be persistent, such as semaphores, within object structures that do need to be persistent and shared".
> 
> I am unsure how to structure this or if this is a good idea. Can anyone please help?
> 
> Kind regards
> Otto Behrens
> +27 82 809 2375
> 
>  <http://za.linkedin.com/in/waltherbehrens>www.finworks.biz <http://www.finworks.biz/>
> Disclaimer & Confidentiality Note: This email is intended solely for the use of the individual or entity named above as it may contain information that is confidential and privileged. If you are not the intended recipient, be advised that any dissemination, distribution or copying of this email is strictly prohibited. FINWorks cannot be held liable by any person other than the addressee in respect of any opinions, conclusions, advice or other information contained in this email.
> 
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20230602/cd64fc5e/attachment.htm>