[Glass] protect temporary files

[James Foster]

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
> 
>  <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.
> 
> 
> 
> On Fri, Jun 2, 2023 at 6:04 PM Norm Green via Glass <glass at lists.gemtalksystems.com <mailto: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
>>> 
>>> 
>>> 
>>> 
>>>  <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 <mailto:Glass at lists.gemtalksystems.com>
>>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>> 
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com <mailto: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/b80ba8ef/attachment-0001.htm>