[Glass] protect temporary files

[Otto Behrens]

Thanks James, will do.

On Fri, 02 Jun 2023, 21:36 James Foster, <Smalltalk at jgfoster.net> wrote:

> My consern with a read lock is that multiple Gems can obtain a read lock
> on the same object. You should consider a write lock instead.
>
> James
>
> On Jun 2, 2023, at 12:17 PM, Otto Behrens <otto at finworks.biz> wrote:
>
> Thanks everyone. I opted for a read lock as a mutex. I release the lock in
> an ensure block. This appears to be the simplest as I cannot rely on
> transactions at the point in time when this is invoked. Let's see
> what happens.
>
> Otto Behrens
> +27 82 809 2375
> [image: FINWorks]
> [image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
> 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.
>
>
> On Fri, Jun 2, 2023 at 6:04 PM Norm Green via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Hi Otto,
>>
>> There is file locking protocol in GsFile under category #locking. There
>> are several caveats and restrictions so be sure to read the methods
>> carefully. Also note that file locking over NFS is buggy and should not be
>> relied upon. If your zip files are on NFS you could create a local (not on
>> NFS) 1 byte file with a known name in a known location and lock it when the
>> zip file is in use.
>>
>> There are other ways to do this as well as James says. For example, you
>> could also use a shared counter (in class System) as your lock bit and use
>> a KeyValueDictionary to map the file name to the shared counter ID.
>>
>> Norm Green
>>
>> On 6/2/2023 5:09 AM, Otto Behrens via Glass 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
>> [image: FINWorks]
>>
>>
>>
>> [image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
>> 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 listGlass at lists.gemtalksystems.comhttps://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>> _______________________________________________
>> 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/20230603/f16a1457/attachment.htm>